Are there any major differences in how the ACE and the CSS handles cookie-based stickyness based on the above listed configurations? From what I've read, the CSS looks for the cookie-value at each GET and forwards traffic based on the value in the cookie. Only when the cookie expires, will traffic be subjected to the LB-algorithm again. But how exactly does the ACE handles this? Does is look for the cookie value at each GET and match it to the corresponding entry in the sticky-database? Or is this method only applied, when persistence-rebalance is configured? If I manually delete the cookie in the browser, will that in any way affect how the ACE handles the subsequent GET or will it simply reuse the sticky parameters applied at the first GET, until the cookie expires and is removed from the sticky-database?
I had a feeling that persistence-rebalance could be the answer. So, would it be safe to assume, that the 'advanced-balance arrowpoint-cookie' feature on CSS is in someway similar to persistence-rebalance, in that it looks for the cookie at each GET and re-loadbalances, if it fails to detect a cookie?
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...