Does the Catalyst 3550/3560 EI support LLQ QoS?? I'm hearing conflicting stories from many people on this subject.
I need to priorities traffic over a BT Les 10(Basically an Ethernet short haul repeater). I have a 3550 at one end and a 3560 at the other... The circuit is uplinked to Fa0/1 on each end.
The CCO docs I have found all say to use WRR(3550) & SRR(3560) L2 QoS. Which would make sense given that the interface is Ethernet not serial. I thought an LLQ egress policy was only supported on serial WAN interfaces? However, a service provider have told me they use LLQ in this scenario. Is this true?
I have tried to test it, all the commands seem to be accepted. I set up fa0/1 as a routed interface on either end and ran OSPF. Then applied the egress LLQ service policy to fa0/1.
But when I issued the "sho policy-map interface fastethernet0/1" I get no matches for dscp46 from the output.
I have used this exact config many times on routers. And I know the packets are being correctly marked. Are they're maybe different commands for LLQ confirmation on L3 switches? Maybe mls qos something
Thanks very much for any help. :)
a detailed explanation of all counters can be found in "Understanding Packet Counters in show policy-map interface Output"
In brief: the counter does not increase, if you have no congestion and the packets are CEF switched. Basically it counts the amount of packets in the L3 queueing system matching the specific class. No congestion means no packets in L3 queueing system, thus (pkts matched/bytes matched) 0/0
As you have a FastEthernet interface it should only count such packets in case you have more than 100 MBit/s worth of traffic.
Hope this helps! Please rate all posts.
Thanks for the quick response. I'll check that out... So are you saying that LLQ is supported on catalyst routed interfaces?
Am I also correct in saying that packets on a router arnt CEF switched over a serial interface?. Is that why I can see all of the DSCP46 packets in a router LLQ egress policy? But not on a switch..
I have taken a look at the doc you kindly suggested. Lots of great info.. And it has confirmed what I asked in my previous post about CEF/LLQ service policys.
However, I would love to have some definate written confirmation that LLQ is supported on catalyst 3550/60 switches.
Has anyone got a working configuration/IOS release perhaps?? I'll log this with Cisco and post the response if no one is sure. I'm sure I'm not the only person with this query.. :)
Just to confirm that LLQ is not supported on catalyst switches...I have received confirmation from Cisco. In this instance you would need to use the following:
2950 SI: CoS&WRR Queuing (SI not L3 aware)
2950 EI: CoS/DSCP&WRR Queuing
3550 SI/EI: CoS/DSCP&WRR Queuing
3560 SI/EI: CoS/DSCP&SRR Queuing
Hope that helps someone out! :)
I have been trying to test a qos implementation on 2 3550 switches. I had finally come to the conclusion that configuring output queues was the only way you could proceed ( allocate bandwidth in times of congestion). You can police, but then you are limiting available bandwidth under normail conditions.I mention this as actually testing the wrr output queues has proved very difficult.In the last test we generated over 60mb of UDP traffic and pushed this down to a 10mb trunk. We have never managed to invoke the output queues. The counters get very close to 10mb, but thats it, ...no queueing!. .........
You are only repeating what cisco tells you to say. To solve the problem of not able to use LLQ, you need to know what LLQ does, and LLQ basically is a priority queue with shaping of the traffic rate on that priority queue. So, the 3560 SRR queuing supports shaping and allows a queue to become priority queue, those 2 commands combines results in exactly what LLQ does. So, LLQ can be emulated in 3560.
When you said that queuing happens "in case you have more than 100 MBit/s" , that statement is not strictly mathematically correct. The problem is that the packets don't come completely smooth. When you have a 90mbps traffic stream for 30 seconds, say downloading somthing, most likely there are at least 5-10 seconds when the traffic is slightly more bursty than 100mbps. And actually during those 5-10 seconds, there is likely 1 second when the traffic is actually more bursty than 1000mbps. And it goes on and on the more details you look into the stream, the more spikes you will find.
I am just speculating. I think we can emulate LLQ by using the SRR shaping on the priority queue.
LLQ is just a priority queue with policing. And the SRR shaping actually somehow polices the queue. I don't know how to apply shaping on the priority queue though.
This is cisco's strategy. It allows the possibility of MPLS-RSVP bandwidth allocation, but the policing is another problem of configuration; it gives a hint, a hunch of LLQ , but the policing is another problem of configuration.
OK, the 3550 may not support LLQ, but 3560/3750 definitely allows emulation of LLQ by using the interface command "priority-queue" and "srr-queue bandwidth shape" command. This is on L2 interfaces. LLQ is basically a priority queue plus shaping. And the 2 commands do exactly just that.