DSCP trust on 6500 and queueing on 3750

Answered Question
Oct 8th, 2008
User Badges:

I have a video device attached to a 6509. It markes voice packets with DSCP46. The blade supports only cos to queue mapping. If I trust the DSCP on that port will it work? How does it decide in qwich queue should it go if the mapping is based on COS?

This 6500 is connected to a 3750 which has another video device attached. When I do "show queueing interface" I get this:

EMHBSSWFE2#sh queueing interface GigabitEthernet1/0/27

Interface GigabitEthernet1/0/27 queueing strategy: none

Here is the interface config:

interface GigabitEthernet1/0/27

description Po1->EMHBSSWFE1

switchport trunk encapsulation dot1q

switchport trunk allowed vlan 1,20,30,40,199-201

switchport mode trunk

srr-queue bandwidth share 10 10 60 20

queue-set 2

priority-queue out

mls qos trust dscp

auto qos voip trust

channel-group 1 mode on

Any help is apreciated ;-)


Correct Answer by allan.thomas about 8 years 9 months ago

Ingress scheduling is not utilised if you do not trust COS on the interface on the 6500, however if you do trust DSCP the egress port scheduling will still be utilised by deriving the cos value from the DSCP using the default dscp-cos mappings.


By default tail-drop will be used unless WRED is specifically configured, but this is dependand on the port capabilities on the given module.


Regardless of whether the video attached device is marking packets with DSCP it should be placed in the appropriate transmit queue. When you enable 'mls qos' dscp 46 will be mapped to cos 5, ordinarily it should be assigned to cos 4. Therefore I assume it is the device which setting the DSCP.


The trouble with setting video with DSCP46 will mean it will share the priority queue with voice rtp which may or may not be desired?


If the later is the case then I would be inclinded to configure the access port for the video device to with cos 4 'mls qos cos 4'


Run the 'show queueing interface ?/?' on the 6500 and it will show you the default cos egress queue maps.


rgds

Allan.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
aghaznavi Tue, 10/14/2008 - 08:44
User Badges:
  • Silver, 250 points or more

1. Catalyst 3750 or 3560 switches and Cisco EtherSwitch service modules. A route map that has an ACL with a Differentiated Services Code Point (DSCP) clause cannot be applied to a Layer 3 interface. The switch rejects this configuration and displays a message that the route map is unsupported.

2. Each port supports four egress queues, one of which (queue 1) can be the egress expedite queue. These queues are assigned to a queue-set. All traffic exiting the switch flows through one of these four queues and is subjected to a threshold based on the QoS label assigned to the packet.

The buffer space is divided between the common pool and the reserved pool. The switch uses a buffer allocation scheme to reserve a minimum amount of buffers for each egress queue, to prevent any queue or port from consuming all the buffers and depriving other queues, and to control whether to grant buffer space to a requesting queue. The switch detects whether the target queue has not consumed more buffers than its reserved amount (under-limit), whether it has consumed all of its maximum buffers (over limit), and whether the common pool is empty (no free buffers) or not empty (free buffers). If the queue is not over-limit, the switch can allocate buffer space from the reserved pool or from the common pool (if it is not empty). If there are no free buffers in the common pool or if the queue is over-limit, the switch drops the frame.

For further information click this link.

http://www.cisco.com/en/US/docs/switches/lan/catalyst3750/software/release/12.2_25_see/configuration/guide/swqos.html#wp1284809


Correct Answer
allan.thomas Tue, 10/14/2008 - 14:25
User Badges:
  • Blue, 1500 points or more

Ingress scheduling is not utilised if you do not trust COS on the interface on the 6500, however if you do trust DSCP the egress port scheduling will still be utilised by deriving the cos value from the DSCP using the default dscp-cos mappings.


By default tail-drop will be used unless WRED is specifically configured, but this is dependand on the port capabilities on the given module.


Regardless of whether the video attached device is marking packets with DSCP it should be placed in the appropriate transmit queue. When you enable 'mls qos' dscp 46 will be mapped to cos 5, ordinarily it should be assigned to cos 4. Therefore I assume it is the device which setting the DSCP.


The trouble with setting video with DSCP46 will mean it will share the priority queue with voice rtp which may or may not be desired?


If the later is the case then I would be inclinded to configure the access port for the video device to with cos 4 'mls qos cos 4'


Run the 'show queueing interface ?/?' on the 6500 and it will show you the default cos egress queue maps.


rgds

Allan.

c.domokos Wed, 12/17/2008 - 05:21
User Badges:

Thanks Allan,


Sorry for getting back so late, got buried under too many things.


Now it is clear to me -thanks again. It is indeed the Video device that sets the DSCP value. Since it is the only device on that port I believe ingress scheduling is not that important, right?

I understand the concern about video and voice sharing the same queue, and I have transmitted it to the customer, however they chose to ignore it. We have a very strange contract where they do not pay for QOS services and just tell us what to configure. So I am stuck with telling them that some things do not make sense.

I spent some time reading the 6500 configuration guide's QOS section. I am still a bit in the dark on the queuing part that is not shown on the drawings. When the packet enters the ingress port I think the order is trust/remark/queue/police-mark-down then transmit to the switch fabric. Then before transmitting the packet the PFC puts it in the outgoing queue and does congestion management, then finally transmits it. Is this right?


Regards

Carol

Actions

This Discussion