I am going to implement LLQ with priority command in an Hub and spoke topology over FR with FRTS.
The 5 minutes input/output rate is around 20% of the frame link (CIR 50% ofthe link).
My doubts are:
-Is LLQ the right congestion managment method to reduce the latency between Citrix Client-Server? I know that Cisco raccomend it to reduce the latency, but half of my traffic to/from the sites is Citrix and it could impact the overall traffic behaviour in negative way. Any experience on that?
-Once a defined service policy has been applied on the subinterface (and relative PVC) the command "show interface serial" shows the physical interface that have FIFO queuing method.
The "showpolicy-map interface" command report the stricty priority queuing method. Are they different queues or is just the priority way to use the physical queue on the interfaces.
-In Cisco site is usually recomended to implement FR fragmentation. I tried to apply it to the map-class FR but the command is not available. If I apply it to the physical interface, in the configuratin it does not show the command. How Can I implement it? how can I verify that the FR is really fragmenting?
When you configure LLQ, you will use the 'priority x' command to guarantee bandwidth x and mimimum latency for the priority class traffic. This command will also police this class of traffic and ensure that the traffic does not overshoot bandwidth x. This way other classes of traffic are not starved. If the high priority traffic rate is above the rate x, then packets from the priority class are dropped.
You should only go by what is shown as the queuing mechanism in the 'show policy-map interface' command. This command will show the CBWFQ and PQ parameters that is part of the LLQ configuration.
To configure frame-relay fragmentation, you have to use the 'frame-relay fragment x' command under the map-class and apply this map-class to the VC or interface. Also, 'frame-relay traffic-shaping' command has to enabled on the physical interface. You can use the 'show frame-raly pvc " command to view the fragmentation information. This link should help you :
It is quite clear the functioning of the LLQ mechanism, but I do not feel confortable from the high percentage of prioritized traffic that can kill the correct functioning of the queue (discarding from PQ and delaying from the other). That was the main topic of the question. Did you ever configured LLQ with the very important traffic as a big percentage of the available Access Rate?
I can access a lab with some 2600, but the it does not allow to implement the fragmentation command under the Frame-relay map class command (I applyed the class in the Sub-Interface and also enabled FR switching):
One word of advice...... for Citrix traffic you would be better off using the 'bandwidth' statement rather than the priority statement. Priority is used for fixed levels of traffic - the citrix traffic has a tendancy to burst. What I noticed was that it was dropping traffic even though I hadnt reached the level defined by the prioirty command. This was due to the traffic bursting. I changed it to bandwidth istead, and it works a treat - priority was actually slowing things down.
The command should be under the frame-relay map-class statement for the FRF12 fragmentation. You also should apply your service policy here, as it allows services policies and fancy queuing per pvc.
We are pleased to announce availability of Beta software for 16.6.3. 16.6.3 will be the second rebuild on the 16.6 release train targeted towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are looking for early feedback from custome...