I've been working on some new context implementations recently, hosted on a redundant pair of ACE30s running Version A4(2.1) and have been investigating a number of minor issues.
One thing I've noticed upon looking in to the ACE behaviour (and some reading of legacy posts on this site) is that the device clears the Windows Scale and SACK options for incoming connections to the VIP. Obviously, these behaviours are quite easy to alter with a Parameter Map, but I'm just trying to understand the downsides of doing so, and why the ACE30 defaults to that behaviour.
Does anyone have any specific advice for default Parameter Map changes they tend to put in place within their configurations? The majority of clients we have connecting are Windows based, with the majority of links having 100+ ms of latency.
There is no downside as such. In fact these are the parameters available to improve the performance of connection between client and server. By default, we don't want to be doing all these things unless client and server support it and hence we strip them all plus it also depends upon different requirements of different customers and hence it is not allowed by default. That's my guess unless there was a specific reason for development.
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...