Create Date: Aug 9 2012 1:55PM
Hello WilsonLet me start to answer this question and hopefully it will make enough sense that it will help you. In XOS we assign traffic to a queue as the traffic ingresses the switch. This allows us to maintain the QoS from the ingress of the switch through the fabric to the egress. The QoS queues, qp1-qp8 are egress queues so that the traffic is shaped or limited. So in the example below you are providing the shaping on egress on each side which is one way to do this. We also can do metering where we drop traffic as it ingresses the port of the switch. So for example you can do a meter on the ingress port at the main site which will drop the traffic at that point. This may not be the best idea as it will allow all traffic across the MAN before it drops. But I mention it for future reference.The information that is in the show port qosm is always egress traffic. So to see the level of traffic from the remote site to the main site you would look at the remote site uplink port and vice versa. If the traffic is staying in QP1 then most likely that is a problem with the precedence of the QoS. XOS allows you to set up many different traffic groups for any type of traffic. When there are more than one traffic group then there is a precedence where one traffic group takes priority over another one. Page 735 of the 15.1 concept guides shows the precedence but here it is."Switches, SummitStack, and""Summit Family Switches""1 ACL-based traffic groups for IP packets (specifies IP address information)""2 ACL-based traffic groups for Ethernet frames (specifies MAC address information)""3 CoS 802.1p-based traffic groups""4 Port-based traffic groups""5 VLAN-based traffic groups""6 DiffServ-based traffic groups"As you can see VLAN traffic is low on the list. If traffic comes into the switch with an 802.1Q tag then the internal .1p bit will take priority over your VLAN setting. This means that most likely the .1p bit will be 0 unless you change it and 0 will fall into qp1 queue.To verify if this is the problem you can disable dot1p examination and see if the traffic falls into the correct queue. So if this is the problem what are the solutions? 1) keep dot1p examination disabled (this can be a problem later on if you use voice as voice traffic will set the 1.p bit. 2) when the traffic egresses either site you can have the switch change the 1.p bit on the fly using config dot1p replacement. If the dot1p values are defined i.e. 0 -qp1, 2-qp2 7-qp8 etc then the switch will change the dot1p bit as the traffic egresses the port to the new value. The other side will see the new .1p bit and place it into the correct queue when dot1p examination is turned on 3) you can use an ACL to look at the IP subnet and then assign it to a qp.Ok does that help? does it raise more questions and do you have any other information that we can use to find the issue.P (from Paul_Russo)