QoS of LLQ with Citrix and Frame Relay

mcardell · ‎02-10-2003

Hi all,

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?

Any helps is really appreciated.

Matteo

s-doyle · ‎02-14-2003

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 :

http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fvvfax_c/vvfvofr.htm#1103368

mcardell · ‎02-17-2003

Hi and thanks for your answer.

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):

2600-2(config-map-class)#frame-relay ?

adaptive-shaping Adaptive traffic rate adjustment, Default = none

bc Committed burst size (Bc), Default = 56000 bits

be Excess burst size (Be), Default = 0 bits

cir Committed Information Rate (CIR), Default = 56000 bps

congestion Congestion management parameters

custom-queue-list VC custom queueing

end-to-end Configure frame-relay end-to-end VC parameters

fair-queue VC fair queueing

fecn-adapt Enable Traffic Shaping reflection of FECN as BECN

holdq Hold queue size for VC

interface-queue PVC interface queue parameters

mincir Minimum acceptable CIR, Default = CIR/2 bps

priority-group VC priority queueing

tc Policing Measurement Interval (Tc)

traffic-rate VC traffic rate

Probably is the version....

2600-2#sh ver

Cisco Internetwork Operating System Software

IOS (tm) C2600 Software (C2600-I-M), Version 12.2(13)T1, RELEASE SOFTWARE (fc1)

TAC Support: http://www.cisco.com/tac

Compiled Sat 04-Jan-03 01:30 by ccai

Image text-base: 0x80008098, data-base: 0x80B62214

ROM: System Bootstrap, Version 12.2(6r), RELEASE SOFTWARE (fc1)

2600-2 uptime is 1 week, 4 days, 22 hours, 24 minutes

System returned to ROM by reload

System image file is "flash:c2600-i-mz.122-13.T1.bin"

cisco 2621 (MPC860) processor (revision 0x00) with 41984K/7168K bytes of memory.

Processor board ID JAD06230AGQ (3016888204)

M860 processor: part number 0, mask 49

Bridging software.

X.25 software, Version 3.0.0.

Basic Rate ISDN software, Version 1.1.

2 FastEthernet/IEEE 802.3 interface(s)

1 Serial network interface(s)

1 ISDN Basic Rate interface(s)

32K bytes of non-volatile configuration memory.

16384K bytes of processor board System flash (Read/Write)

Configuration register is 0x2102

2600-2#

Thanks

Matteo

alan.weadick · ‎02-21-2003

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.

Hope that helps....

Alan

mcardell · ‎02-21-2003

Thanks very much for your help really appreciated.

I tried few times to put the fragmentation command into the frame-relay- map-class but it was not possible.

What device did you implemented and with what IOS version?

I am actually working with 12.2(13)T1 IP and cisco 2621.

Did you work with a big citrix environment?

We had problem to size the network because the Thin Client seemed to need more bandwidth than the usual Citrix reccomendation (20Kbps).

Can you give me some value around the access rate and the guaranteed bandwidth some indicative site?

thanks

Matteo