3750 - problems with incoming traffic marking

[tdouk]

Hello all

We are experiencing problems with a 3750 switch in our test environment. The switch is a WS-C3750G-24TS-E1U and is supposed to forward multicast streams to the multicast routers through a trunk optical port. The streams consume a total of about 100Mbps and are received through a GigE electical interface that operates in access mode.

We were supposed to mark the incoming multicast traffic with the appropriate CoS values. We tried to implement this in the simplest way possible:

interface GigabitEthernet1/0/1

description ##MulticastTraffic##

switchport access vlan 100

switchport mode access

mls qos cos 5

mls qos override

end

When we added the "mls qos override" command, immediately the streams began experiencing heavy packet loss. When we left that command out, the stream were forwarded without lost frames (but of cource no marking took place then).

We are using the "c3750-ipservices-mz.122-25.SEE2" image.

Dscp rewrite is enabled and sdm settings are the default (access-desktop).

I am afraid that if such basic functionality does not function correctly then I must doing something horribly wrong. Can anyone provide any suggestions about possible ways to overcome this problem.

Thank you.

[mheusinger]

Hello,

what is your queueing config looking like? There should be something like globally "mls qos", "mls qos srr-queue...", "mls qos queue-set 1 ..."

and also like

interface GigabitEthernet0/1

queue-set 1

srr-queue bandwidth share 1 70 25 5

priority-queue out

You could be using shaped round robin queueing limiting your traffic throughput.

A detailed description of 3750 QoS confiiguration can be found at "Configuring QoS" in the 3750 configuration guide

http://www.cisco.com/en/US/products/hw/switches/ps5023/products_configuration_guide_chapter09186a00805a6504.html#wp1196344

Hope this helps! Please rate all posts.

Regards, Martin

[swaroop.potdar]

At first glance looking at the interface config,

1) You dont need the "mls qos cos x override" command. This is required to replace the existing cos value preset into Dot1Q tagged frames.

2) Since you have a access port for the multicast source/headend, you can simply use the "mls qos cos" command to set the default port cos value into the Dot1Q Tags for the Access Vlan defined on the access port.

DSCP rewrite enabled will reqrite the IP header of the packets using the default COS-DSCP map. This is also ok if you want to further categorize the downstream towards the destination.

With 100 MB of total stream traffic ideally you shouldnt be seeing drops, even if you enable the command "mls qos cos override", which is not required in your scenario.

TO further answer your question, why you see drops, when you enable the override command, you topology and the complete config done on this switch needs to be understood, as for all you know it may be a bug as well.

HTH-Cheers,

Swaroop

[tdouk]

Sorry for my late response

Mls Qos is activated. No traffic limiting of any sort is used in the switch.

The output of sh mls qos interface g1/0/1 queueing is:

GigabitEthernet1/0/1

Egress Priority Queue : disabled

Shaped queue weights (absolute) : 25 0 0 0

Shared queue weights : 25 25 25 25

The port bandwidth limit : 100 (Operational Bandwidth:100.0)

The port is mapped to qset : 1

The same applies for the uplink port of the switch that forwards the streams

to the traffic sink.

In any case the traffic forwarded is well bellow 100Mbps so there should be

no congestion is expected in the switch.

We try to do some further tests regarding this issue. What we found is the

packet loss occured only when we used Cos value=5 to mark the incoming

traffic. When we changed to CoS=4 or 6, no packet loss occured. I do not

know if Cos value 5 has some other special usage, but when we used it for marking

the switch began dropping almost 50% of the incoming multicast traffic.

What was odd is that the output of show ip interface for both

incoming and uplink interfaces shows no discarded packets.

The only place we could found that verified that the packets were indeed discarded

was from the output of the command:

sh platform port-asic stats drop

The frames according to the command were lost in the output interface

of the switch connecting to the traffic sink. The output interface is also

a gigabit ethernert with traffic load well bellow 100Mbps.

Kind Regards