cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
925
Views
0
Helpful
8
Replies

QoS - Ingress Port Queuing (SP or default) based on CoS?

kfarrington
Level 3
Level 3

Guys,

the following URL is excellent for the QoS flow through a 6500. Also had an excellent briefing off a mate in my team :)

http://www.cisco.com/en/US/customer/tech/tk543/tk762/technologies_white_paper09186a00800b0828.shtml

One question on this. It states the following :-

A frame enters the switch and is initially processed by the port ASIC that received the frame. It will place the frame into a Rx queue. Depending on the Catalyst 6000 family line card, there will be one or two Rx queues.

The port ASIC will use the CoS bits as an indicator of which queue to place the frame into (if multiple input queues are present). If the port is classified as untrusted, the port ASIC can overwrite the existing CoS bits based on a predefined value.

The statement "The port ASIC will use the CoS bits as an indicator of which queue to place the frame into"

does this mean that the frame can only be put into the Rx queue based on an L2 (isl, dot1q) CoS value, OR can the frame be place in an Rx queue based on an L3 DSCP or ip prec value? ALSO, what if there is no CoS value, (ie the frame is not from a trunk, ie untagged)

then it goes off for internal DSCP markings (which I understand all about now I hope) :)

Could someone please clear this small point up for me.

Many thx indeed,

Ken

1 Accepted Solution

Accepted Solutions

johgill
Level 1
Level 1

Ken,

The rx queueing can ONLY be done based on L2 CoS bits, not DSCP in the IP header. The PFC can look deeper into the frame but that is after the ingress queue since PFC QoS is performed on the supervisor.

PFC QoS marks all traffic received in untagged frames with the ingress port CoS value. By default the ingress port CoS value is 0 and is queued as such.

to configure ingress port cos: mls qos cos port_cos

Remember also:

PFC QoS marks all frames received through untrusted ingress LAN ports with the ingress port CoS value. PFC QoS does not implement ingress port congestion avoidance on untrusted ingress LAN ports. There is no distinction between untrusted-tagged and untrusted-untagged.

To use the ingress port CoS value applied to untrusted traffic as the basis of egress DSCP, configure a trust-CoS policy map that matches the ingress traffic.

Regards,

John

View solution in original post

8 Replies 8

simonstoll
Level 1
Level 1

Hi Ken

As far as I know there is realy just a lookup of the COS Value at the ingress scheduling. There is no way to map an ingress DSCP to a COS at this stage. What happens if this is not a .1q tagged frame? If I'm correct it depends on the trust state of the port and the default cos value assigned to it. If the port is set to untrust (default) the cos will be rewriten to 0 (also default). If the port is set to trust cos, it will keep it's cos value if there is one. If there is none, it will be set to the default port cos (can be specified to any cos value, default 0). I'm not 100% sure about this, but maybe there is an expert out here who knows it, I would also be interessted in his answer.

But actualy in most cases an ingress scheduling is not realy necessary, because as long as the switches are non blocking, mean aslong as the ports can move the traffic on to the switching backplane, there is realy no need for scheduling at this stage. And the Cat6K is realy fast in that :-) I think it's more of a lab question, and even there it would be hard to provoke a situation where it would be needed. It's not someting for reallife.

Simon

lgijssel
Level 9
Level 9

Well Ken,

I assume that it works as follows:

The switchport is either configured to trust CoS or DSCP. If DSCP is trusted it will use the dscp-to-cos mapping to determine the corresponding cos value.

Subsequently, the packet is written to the corresponding Q, effectively applying the desired QoS. It is important to realize that internally, the switch knows about CoS and DSCP. If the packet is subsequently transmitted over a dot1q trunk, the corresponding CoS is applied.

The relation between CoS and DSCP can be displayed using: sh mls qos map

Regards,

Leo

Hey dude, (also thx Simon also)

This is the thing, according to the documentation, the DSCP-COS mappings are for mapping the internal DSCP value on the PFC (i think) which come well after the input queue assignment phase so i would like to think that the input ASIC says what you are implying.

The extrat from the doc is

As mentioned earlier, the switch uses a DSCP value internally to assign a predetermined level of service to that frame. As a frame enters a trusted port, the administrator can configure the port to look at either the existing CoS, IP precedence, or DSCP value to set the internal DSCP value. Alternatively, the administrator can set a predefined DSCP to every packet that enters the port.

it says "the administrator can configure the port to look at either the existing CoS, IP precedence, or DSCP value to set the internal DSCP value" It does not say that it will look at the COS, IPPREC or DSCP to move the incoming packet into the relevant Rx Q?

Am I being a little silly here? Sorry if I am :)

I suppose what I am trying to say is. A frame comes into a switchport that has two queues, SP and default. If it comes in on a non-trunk port (has no CoS marking) how would you determine how to get a frame into a specific Rx queue (if you have two of them) based on CoS?

Kind regards,

Ken

johgill
Level 1
Level 1

Ken,

The rx queueing can ONLY be done based on L2 CoS bits, not DSCP in the IP header. The PFC can look deeper into the frame but that is after the ingress queue since PFC QoS is performed on the supervisor.

PFC QoS marks all traffic received in untagged frames with the ingress port CoS value. By default the ingress port CoS value is 0 and is queued as such.

to configure ingress port cos: mls qos cos port_cos

Remember also:

PFC QoS marks all frames received through untrusted ingress LAN ports with the ingress port CoS value. PFC QoS does not implement ingress port congestion avoidance on untrusted ingress LAN ports. There is no distinction between untrusted-tagged and untrusted-untagged.

To use the ingress port CoS value applied to untrusted traffic as the basis of egress DSCP, configure a trust-CoS policy map that matches the ingress traffic.

Regards,

John

Can I just say a BIG thanks to all (Leo, John and Simon) for there help with this.

It is a very important concepts to understand, and I think im well on the way there :)

Brill,

Ken

I have just noticed this on a 6500 config

set qos map 1p1q4t rx 1 1 cos 0

set qos map 1p1q4t rx 1 1 cos 1

set qos map 1p1q4t rx 1 2 cos 2

set qos map 1p1q4t rx 1 3 cos 3

set qos map 1p1q4t rx 1 3 cos 4

set qos map 1p1q4t rx 2 1 cos 5

set qos map 1p1q4t rx 1 4 cos 6

set qos map 1p1q4t rx 1 4 cos 7

set qos drop-threshold 1p1q4t rx queue 1 50 60 80 100

I assume then that you can manipulate any CoS value received in a tagged L2 frame to which ever queue you want, ie Q1 (default) or Q2 (SP).

Is that correct, if so it is neat :)

Yes, that is exactly correct, this is known as "giving one enough rope to hang themselves"

That made me fall off my chair!

Funny!!

:)

I will leave this alone me thinks!

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: