Hi,

"ip nbar protocol-discovery" was needed in older IOS versions, but this requirement has been removed. I forgot the exact IOS version though, when this was done, but as you indicate that match protocol gives you matches for other protocols, you should be fine.

Can you please check the ports CITRIX is using in your environment and compare them to "show ip nbar port-map"? Citrix traffic can only be detected by NBAR, if the port matches the (pre-)configured one.

In case you are using different ports, then you can adjust that with configuring "ip nbar port-map citrix ...".

Hope this helps! Please rate all posts.

Regards, Martin

Narayan's recommendation is excellent, some other points, though.

I see the marker is on a parent FastEthernet rather than the subinterfaces. Check that you are seeing Citrix, and other hits, within the marker service policy on that interface. Besides Martin's suggestion to confirm the port usage, I wonder whether the policy should be applied to the subinterfaces.

I don't see any bandwidth allocation for class 25?

I see you're using FQ in the class-default. Just be aware on non-7500 platforms, every FQ flow competes for bandwidth against the other defined classes. This might not be what you intended.

I also see you're using WRED in the class-default. The default's early drop policy default settings are usually not advantageous for non-TCP traffic.

There is a PDLM for Citrix that can match against the Citrix's internal priority. Don't recall whether the later 12.4 images have that version. Useful if you want to treat Citrix "screen scraping" traffic different from Citrix printing or file copying.

Lastly, you might consider whether the MTU should be adjusted to account for IPSec overhead. (Often helps improve throughput performance.)