We have a problem where when our wan circuit fills to almost 100%, file/folder browsing becomes very slow. Maybe 15-25s to open a folder. So a user could wait 60-100s if they have to drill down 4 folders. Users are complaining a lot when this happens. It's becoming such a problem that upper management is questioning our investment in cisco waas.
Anyone else notice this behavior? Is this normal?
It doesn't seem like I should/could solve this with qos (we already have qos for VoIP and SAP). It also is not practical to upgrade all our circuits. The circuit would probably still fill to 100% at times even if we doubled our bandwidth everywhere.
version is 4.1.1c
datacenter at corp office. 60 branches across US.
2 core wae 7341 devices in the corp datacenter
core wae's connected to 2 7606 wan routers at corp datacenter
You do have the ability to bump up the DSCP values for the high priority messages (locking/authentication/etc.) but I don't think that will assist in browsing. If your pipe is filling to 100%, it's just taking time for the directories metadata to traverse the pipe.
Are you getting good optimization on the traffic in the WAN?
So you're talking about the setting under Dashboard - Manage Device Groups - "wafs core cluster" name - core server settings?
I think we're getting decent optimization. Under "Top 10 Application by % Reduction - Last Day", WAFS is 65%, Email is 50%, Web is 32%. Web, email, wafs are our top 3 bandwidth hogs, in that order. I wish web was higher. I'm guessing it's not because SSL traffic isn't reduced much.
I'm surprised that more people haven't complained about this. Does everyone just have larger circuit bandwidths?
Does the WAFS Edge serve the files quickly, just browsing remote servers is slow? I have many clients running Core/Edge WAFS over sub T1 speeds and things are running pretty well. I think that even with WAAS, the fact you are still hitting 100% WAN saturation shows you have a ton of congestion still happening.
There is something else you can try if you are want to. You can go into the CIFS classifier (I usually do all my application policies in the AllDeviceGroup) and change the DSCP Marking there for ALL of CIFS traffic that is being optimized by WAAS if your network will accept the markings from WAAS. This is a newer feature in 4.1.1 and would allow you to see if that will help with your situation.
The files can be served quickly, as long as the circuit is not full.
One reason our wan circuit might fill is because of a "cold" CIFS file pull. We can't preposition everything since we only have 30-40G of usable cifs cache on our NMs.
Other than that, http downloads or email attachments happen often enough and will fill a 768K circuit.
Our network won't accept the markings unless we change our QoS configs. I'm not sure we could do that without choking out some other app. VoIP and SAP are our top 2 queues. If we put WAAS/CIFS after that, we could choke out our internet traffic.
VMware Trunk Port Group is supported from ACI version 2.1
VMM integration must be configured properly
ASA device package must be uploaded to APIC
ASAv version must be compatible with ACI and device package version
In the Previous articles of ACI Automation, we are using Postman/Newman as the Rest API tool to automate the ACI Configuration.
In this article I’m going to discuss on usin...
One of the first steps in building your ACI Fabric is to go through Fabric Discovery. While Fabric Discovery is usually a straightforward process, there are various issues that may prevent you from discovering an ACI switch. This article wil...