Print optimisation is turned and the graphs show a optimisation of traffic reduction up to 90%. This great of course, but why are users still complaining about slow print jobs. The print server is located centrally and behind a 4Mbit WAN link.
Would'nt is be better to use the local WAAS CUPS server anyhow?
The centralized print option does have performance impacts from WAN bandwidth and latency factors, so it will definitely be slower the LAN printing. Even reducing the bw by 90%, all the packets still have to get to the print server, be processed, and return over the WAN to the printer. I would also have the print server admins double check that the server is running OK and is sized appropriately for extra print queues. Another thing I ALWAYS check is speed/duplex settings on the server/switch, WAE/switch, and printer/switch. I have seen a lot of times where a mismatch there really shows up more with WAAS then without it as optimized traffic may have to back off to wait for a client to catch up.
If you are starting to explore local options of printing, I always start with the Windows on WAAS option running on a virtual blade. This is great if you have the hardware, however requires the WAVE appliances. This is not an option for everyone, so I would look at the Samaba server last. It is deployed at quite a few of my customers, but can be rather cumbersome to administrate. It definitely works, but it is considered legacy going forward in new code.
Implementing the built legacy CUPS server is the fastest way to move forward. Even when using SAMBA a CUPS server is used anyhow when using Linux.
I do have some issues configuring legacy print services. The CUPS service is running and I have configured a printer to it, but the central site does not see this configuration as I would like to use the centralized printer driver service.
Topology & Design:
Two ACI fabrics
Stretching VLANs using OTV
Both fabrics are advertising BD subnets into same routing domain
Some BDs(or say VLANs) are stretched, but some are not.
Endpoints can move betwee...
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
Topology &Design:Traffic flow within same fabric:Endpoint moves to Fabric-2Bounce Entry Times OutTraffic Black-holedSummarySolutionAppendix:
In the Previous articles of ACI Automation, we are using Postman/Newman a...