I am not sure why "cookie offset 33 length 3" is required here. Again the offset value 33 and length value 3 is actually configured in bytes and not exactly based on number of characters in the cookie value. What happens if you remove the
"cookie offset 33 length 3" from the sticky configuration ? can you try removing this command and check if it works ?
By default if ACE cannot see that a user is already stuck to a server it will load balance that request normally which in your case could be round-robin(default) if you have not configured any specific LB method.
Now, in your case once the client sends a request and server sets the "Cookie" in response you should see an entry in "show sticky database". If the client comes back with same cookie, ACE should send the request to the same server.
You should see "show sticky database" output, also install "Live" HTTP utility in Mozilla or iehttp in IE and see if the client is coming with same cookie again? At the same time show sticky database should show what cookie value ACE is looking for when client comes back. Other option is to take packet capture on ACE itself and see what client is coming with.
Your first requirement should be fulfilled since by default the LB method is round-robin. Once the client comes with a cookie and there is an entry already the connection is stuck to the same server. If it is not then there is a misbehave and pcaps as well as outputs above mentioned should help.
Lets say for your client request, server sent in response the following cookie "JSESSIONID=C333C37FCF083D210A639ABB8BB9DB21.S01". Ace will hash the cookie value "C333C37FCF083D210A639ABB8BB9DB21.S01" and associates the hash value with the real server in the sticky table entry. So when your Authorize SRV sends a login request to the ACE, if the cookie value is the same as
"C333C37FCF083D210A639ABB8BB9DB21.S01" then it will send the request to the same real server based on the sticky table entry.
You can check the sticky table using the following command to see what cookie value is associated with which real server:
show sticky database http-cookie "C333C37FCF083D210A639ABB8BB9DB21.S01"
To confirm if the "client" and "Authorize SRV" send the same cookie in their request you could take a packet capture on the ACE. If the cookie value is different then the ACE will check the sticky table and according to the match it will send to the correct real server.
Could you please confirm the cookie sent by both client and the Authorize SRV are same but still the ACE sends it to a different server ?
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...