When a link in the (Layer 2) network was broken, traffic was switched (spanning tree protocol MSTP) to a link with a lower bandwidth, that could not cope and became congested.
This resulted in some catalyst switches no longer being manageable, as high-bandwidth user data swamped the management traffic, which was then, more often than not, dropped.
How can one ensure that such management traffic from the switch itself gets a high priority assigned to it by the sending switch ?
The other switches use "mls qos trust cos" on the 802.1q trunks, for which the management vlan of the switches is not the native VLAN.
The text you refer to explains in some detail how QoS handles packets incoming from an external port.
I have tried to apply a service-policy to the vlan interface corresponding with the management interface of the L2 switch (C2960) but this was not accepted.
I didn't want to burden the CPU with service-policies and access-lists for the outgoing interfaces as they carry a considerable amount of traffic.
If management of the switch is by HTTP, how do I ensure that HTTP to/from the management address of the switch gets priority (and other HTTP traffic does not) ?
This is not clear to me from the text.
The document you refer to is not unknown to me. Lots of passages are repetitions of other documents. However, in the table of contents, the same items appear, all handling marking, policing, queuing. They keep referring to ports.
"How can one ensure that such management traffic from the switch itself gets a high priority assigned to it by the sending switch ? "
That's not always easy to accomplish for device sourced traffic. (BTW, you might not need "high priority", just need to recognize and treat your "management" traffic as special.)
Fortunately, if your "management" traffic is in a dedicated VLAN, this could provide a good hook for this traffic. Specifics for "how", depends much on the platforms and your network setup.
BTW, some devices, I believe, already mark some device source traffic and/or offer a configuration option to do so.
QoS on L2 is hardware dependent.
For the following Catalysts:
The CPU (called Supervisor) has 16 queues, which are all then channeled into the Queue number 2 (if the numbering is 1,2,3,4. In some outputs, the numbering is 0,1,2,3, and then it's queue number #1). It is automatically the third threshold, which is equaled to the second threshold.
So to increase the priority of management traffic, just allocate some resources to it. No mapping is necessary, as the mapping is important for passing traffic. For the Supervisor originated traffic, the mapping is not considered, and it ends up automatically inthe Q2T3 (second queue third threshold).
Actually, this is why you can't allocate 0% of buffers to the second queue - it has to have at least 1 percent.
This is useful.
Do the 16 supervisor queues refer to the priority-levels ?
There is still the question about setting the CoS or DSCP value in this outgoing traffic, as the following (L2) switch will base its QoS treatment on the QoS marking in the received packets.
If it has no superior QoS marking, this traffic will be treated without any priority whatsoever, and that is not the intended situation. The architecture consists of a ring of L2 switches (more than 10) witch coupling to L3 devices at only 2 of the 10 (or more) switches.
Where can I find information on the Cisco Website regarding QoS for device-generated traffic for the 2950 - 2950G and 3550 series switches ?
If all switch locally source traffic is directed to one queue, that's find, but without some kind of tagging, this distinction would be implicitly lost on next switch.
Also, what queue does transit traffic go to? To get the benefit of "no mapping", on the souce switch egress, we optimally need transit traffic to default to another queue.
I may recommend changing the TOS value on telnet with the command 'ip telnet tos'.
You can set the TOS value to 0xB8 which equals to DSCP 46 - COS 5 - High Priority by default
If you were to set this command on the affected switch and the neighbor switch, you could've telnet from the neighbor switch entering the affected switch with priority queueing and the affected switch would respond to your query with PQ as well.
Depending on the hardware in question, you may need to enable PQ on the switchport.