cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
6482
Views
4
Helpful
12
Replies

Prioritization (QOS) for Citrix

kradjesh13
Level 1
Level 1

Hi all,

I tried to apply QOS for Citrix traffic to one of our remove sites. For me the configs seems to be right, but for some reasons the prioritization is not working out. I also enabled ip nbar on the atm interface. Can some one help me out in fixing up the issue.

Note : In the below output only 2 packets are seen to be captured. But i know the whole link is used for the Citrix traffic transfers.

class-map match-any CITRIX

match protocol citrix

match access-group 110

class-map match-any RDP

match access-group 103

!

!

policy-map OUTBOUND

class CITRIX

priority percent 50

class RDP

priority percent 10

class class-default

fair-queue

access-list 103 remark RDP-Priorisation

access-list 103 permit tcp any any eq 3389

access-list 110 remark Citrix-Priorisation

access-list 110 permit tcp any eq 2598 any

access-list 110 permit tcp any any eq 2598

access-list 110 permit tcp any eq 1494 any

access-list 110 permit tcp any any eq 1494

Service-policy output: OUTBOUND

Class-map: CITRIX (match-any)

2 packets, 94 bytes

5 minute offered rate 0 bps, drop rate 0 bps

Match: protocol citrix

0 packets, 0 bytes

5 minute rate 0 bps

Match: access-group 110

2 packets, 94 bytes

5 minute rate 0 bps

Queueing

Strict Priority

Output Queue: Conversation 40

Bandwidth 50 (%)

Bandwidth 256 (kbps) Burst 6400 (Bytes)

(pkts matched/bytes matched) 0/0

(total drops/bytes drops) 0/0

Thanks

Rajesh

1 Accepted Solution

Accepted Solutions

Hi Rajesh, I see from youe above output that RDP class is matching quite a bit of traffic now so it looks like it is working although there are still only 3 matches on the Citrex class. As nbar protocol discovery did not match any citrix traffic it's looking like either there is no citrix traffic hitting the router or it's not on the standard port-map that nbar uses. Can you confirm the port your citrix traffic is using?

r1#show ip nbar port-map

port-map bgp udp 179

port-map bgp tcp 179

port-map citrix udp 1604

port-map citrix tcp 1494

View solution in original post

12 Replies 12

mark.edwards
Level 1
Level 1

can you enable "ip nbar protocol-discovery" ont the inbound interface for traffic hitting the router. The do "show ip nbar protocol-discovery" to see if any traffic is matching the NBAR protocol groups. If traffic is hitting the router as expected can you show the config of the ourbound interface where the service polciy is appiled?

Hi,

did you overload the interface with traffic? If not, the counters will not encrease. The reason is, that the counters will not "see" packets CEF or fast switched. Only those packets queued will be seen, as only those will have to be treated by the CPU of the router.

You are doing CBWFQ and this is only invoked, when there is an overload situation. So use a traffic generator and make sure you get some drops as a sure indication of overloading the interface. If the counters still are not increasing, then the policy does not work and further investigations are needed.

Regards, Martin

martin, you gave exactly the same responce to a previous QOS question. Did you actually read either question in full?

Yes I did and the same answer is applicable in both cases. The counters might just be zero or "low" because not every packet is counted, which is forwarded by the router. If this is the case - in both posts to be verified - there is no problem, but only the default behaviour encountered.

The link to read about this is:

"Understanding Packet Counters in show policy-map interface Output"

http://www.cisco.com/en/US/tech/tk543/tk760/technologies_tech_note09186a0080108e2d.shtml

Regards, Martin

EDIT: Having a closer look at the counters in both cases there are practically no dropped packets in the default class. This could very well mean, that no congestion for the classes in question has ever been experienced.

To the original poster:

Can you configure a policer, which counts every packet? Could look like this:

policy-map MyMap

class MyTraffic

police 1000000

conform-action transmit

exceed-action transmit

violate-action transmit

bandwidh ...

This policer will only be used as a packet counter. If this will not give any matches, have a closer look to your ACL. Does it really match your traffic? Consider using NBAR "match protocol citrix" only and adjust the TCP/UDP port maps for citrix.

Regards, Martin

Hi Mark / Martin

I applied the ip nbar command in the ethernet interface and still i don't find any citrix traffic being captured. In the WAN interface not only citrix but almost every counter is 0 and its some thing real bizza.

interface FastEthernet0/0

description XYZ LAN

ip address xxx.xxx.xxx.65 255.255.255.240

ip nbar protocol-discovery

duplex auto

speed auto

#sh ip nbar protocol-discovery

ATM0/0/0.1

Input Output

----- ------

Protocol Packet Count Packet Count

Byte Count Byte Count

5min Bit Rate (bps) 5min Bit Rate (bps)

5min Max Bit Rate (bps) 5min Max Bit Rate (bps)

------------------------ ------------------------ ------------------------

bgp 0 0

0 0

0 0

0 0

citrix 0 0

0 0

0 0

0 0

cuseeme 0 0

0 0

0 0

0 0

custom-01 0 0

0 0

0 0

0 0

custom-02 0 0

Martin, i have overloaded the router with Citrix traffic and even i find difficult to type the commands since such a very heavey citrix traffic is being generated. But still no use

Any how thank for all your tips.

Rajesh

Hi, can you confirm this is on the correct interface as you mention ethernet but the output shows ATM0/0/0.1? If this is on correct interface and shows no traffic, can you confirm traffic is hitting the interface with IP accounting?

Yes, i checked the configs to the interface in which i applied ip nbar commands. For your reference i pasted the outputs which i took from the WAN interface. So ip nbar command is applied on both the interfaces which is ATM and FastEthernet interface.

Virtual-Access2 is up, line protocol is up

Hardware is Virtual Access interface

MTU 1500 bytes, BW 512 Kbit, DLY 20000 usec,

reliability 255/255, txload 23/255, rxload 1/255

Encapsulation PPP, LCP Open

Open: IPCP

PPPoATM vaccess, cloned from Dialer1

Vaccess status 0x44

Bound to ATM0/0/0.1 VCD: 1, VPI: 8, VCI: 35, loopback not set

Keepalive set (10 sec)

DTR is pulsed for 5 seconds on reset

Interface is bound to Di1 (Encapsulation PPP)

Last input 00:00:00, output never, output hang never

Last clearing of "show interface" counters 1w2d

Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0

Queueing strategy: fifo

Output queue: 0/40 (size/max)

5 minute input rate 0 bits/sec, 1 packets/sec

5 minute output rate 48000 bits/sec, 0 packets/sec

6509640 packets input, 536627972 bytes, 0 no buffer

Received 0 broadcasts, 0 runts, 0 giants, 0 throttles

0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort

10042284 packets output, 3551444033 bytes, 0 underruns

0 output errors, 0 collisions, 0 interface resets

0 output buffer failures, 0 output buffers swapped out

0 carrier transitions

sh policy-map interface atM 0/0/0.1

ATM0/0/0.1: VC 8/35 -

Service-policy output: OUTBOUND

Class-map: CITRIX (match-any)

3 packets, 141 bytes

5 minute offered rate 0 bps, drop rate 0 bps

Match: protocol citrix

0 packets, 0 bytes

5 minute rate 0 bps

Match: access-group 110

3 packets, 141 bytes

5 minute rate 0 bps

Queueing

Strict Priority

Output Queue: Conversation 40

Bandwidth 50 (%)

Bandwidth 256 (kbps) Burst 6400 (Bytes)

(pkts matched/bytes matched) 0/0

(total drops/bytes drops) 0/0

Class-map: RDP (match-any)

3333 packets, 352492 bytes

5 minute offered rate 0 bps, drop rate 0 bps

Match: access-group 103

3333 packets, 352492 bytes

5 minute rate 0 bps

Queueing

Strict Priority

Output Queue: Conversation 40

Bandwidth 10 (%)

Bandwidth 51 (kbps) Burst 1275 (Bytes)

(pkts matched/bytes matched) 111/17057

(total drops/bytes drops) 3/4091

Thanks

Rajesh

Hi Rajesh, I see from youe above output that RDP class is matching quite a bit of traffic now so it looks like it is working although there are still only 3 matches on the Citrex class. As nbar protocol discovery did not match any citrix traffic it's looking like either there is no citrix traffic hitting the router or it's not on the standard port-map that nbar uses. Can you confirm the port your citrix traffic is using?

r1#show ip nbar port-map

port-map bgp udp 179

port-map bgp tcp 179

port-map citrix udp 1604

port-map citrix tcp 1494

Yes mark i can see the ports 1604 and 1494 when i did a show ip nbar port-map.

sh ip nbar port-map

port-map bgp udp 179

port-map bgp tcp 179

port-map citrix udp 1604

port-map citrix tcp 1494

port-map cuseeme udp 7648 7649 24032

port-map cuseeme tcp 7648 7649

port-map dhcp udp 67 68

port-map dns udp 53

port-map dns tcp 53

sh access-lists

Extended IP access list 103

10 permit tcp any any eq 3389

20 permit tcp any eq 3389 any

Extended IP access list 110

10 permit tcp any eq 2598 any

20 permit tcp any any eq 2598

30 permit tcp any eq 1494 any

40 permit tcp any any eq 1494 (3 matches)

50 permit tcp any eq 1604 any

60 permit tcp any any eq 1604

Only three packets are matched with port 1494. When i did a "bebug ip packet 110 detail" i couldn't see any packets matching ACL 110.Is there any other commands or debug comands to check the ports for the existing traffic.

Thanks

Rajesh

Hi,

it looks to me as if your CITRIX implementation does not use the ports NBAR is looking for. Can you check the ports CITRIX is using, or whether there is any tunneling/encryption applied to CITRIX traffic. The last thing that could happen: are you sure about CITRIX or could it be MS remote desktop or other stuff?

Just for testing I would specify the CITRIX server IP and not be port specific in the ACL.

Regards, Martin

Thanks for your help guys..

Today morning i noticed that the packets are being captured and working fine. As Martin said, thinking of discussing with the Citrix administrator to know the exact ports and to apply ACL's for better performance.

Once again thanks for all your help and support.

Review Cisco Networking for a $25 gift card