system image file: [LCP] disk0:c6ace-t1k9-mz.A2_1_1a.bin
We have 2 webservers (load balanced) & 2 application servers(load balanced).Cookie based stickiness is currently used on Web & Application servers.
1.Client opens the url http://...There is always a dual session whenever the client opens the url.One is for Java & the other for html.
Most of the times when the client types the url, the dual sessions goes to one Webserver as per round robin (eg web server 1) & the webserver 1 communicates with Application server as per round robin (eg.application server 1).
Now at times when the client types the url, the dual sessions gets split which means one session goes to one webserver & the other session goes to second webserver.Ideally it should not as per the application demands.
When this happens, both the webservers communicates with both the application servers.Here is where the problem happens.The client is asked for the login page again which indicates that the client has went to the second application server for the login.
What ideally should happen is the client should stick to the same application server depending up the sticky timeout.
Foll. is the output of show conns when prob occurs:
Primary-ACE/DMZ2# sh conn serverfarm SF-8888
conn-id np dir proto vlan source destination state
You have split the APPS and WEB between different contexts.
This is your problem.
The context are independent and do not share the sticky info.
So, to make it simple, merge the 2 contexts into a single one and everyting should be ok.
If this is really really really really important to use virtualization, you could use cookie insert on the WEB context and then reuse the same cookie name on the app context with static entries pointing the cookie_inserted value from web to the same server in app.
Is client hitting the Webserver farm (in web server context) and then Web servers hitting the APPs Servers in the APPS server context?
If thats the case (only Web servers are App server clients and client is not hitting application serverfarm ) then you can use source ip based sticky in APP server farm which will ensure that one web server sticks to a particular APP server and it never changes the APP server.
Following example will insert cookie named "Mycookie" in the server responses from APP1 rservers to the client
rserver host App1-Srvr1
ip address 192.168.1.1
rserver host App1-Srvr2
ip address 192.168.1.2
serverfarm host APP1-SFARM
class-map match-any APP1-VIP
2 match virtual-address 10.10.10.1 tcp eq www
sticky http-cookie MYcookie App1-sticky
policy-map type loadbalance first-match APP1-POLICY
When we use IP based in the APP zone, the problem is when we have one web server down,Web server 2 will always stick to one application server & that way we won't be able to acheive load balancing in the APP zone.
Moquery is the command line cousin of Vizore, it's very helpful and efficient sometimes during the troubleshooting. This article aims to provide moquery cheat sheet to the users for some most common seen scenarios.
Here is the checklist before customers/partners contact Cisco TAC:
Firmware Version of APIC and Switch
Download Switch and APIC techsupport logs
Problem description (Symptoms with details)
Business impact (eg, what kind of services...
moquery usageAPIC moquerySwitchmoquery
This document discuss a common issue observed during the VMM integration & VM workload migration to ACI fabric.
VMware Virtual machines are hosted in Cisco UCS-B seri...