Customer is experiencing a problem resulting in the ACN software resolving the host.domain.com twice. Webapplication https://host.domain.com/webapp/index.jsp. The customer uses a ACN to proxy the https request. The host.domain gets resolve to 1 of 4 available application servers (webserver). At the application login page (index.jsp) the user is successfully authenticated by the application's Login servlet on webserver 1. The user is then redirected to the select application, local to the webserver 1. It appears that when the ACN receives the response from webserver 1 with the fully qualitfying URL. The redirection cause the ACN to resolve the host.domain against DNS and as a result, the user's browser is redirected to a different webserver. The users previous session is no longer valid, breaking the client/webserver trusted relationship
If the above user uses 1 of the 4 available IP address on the DNS entry, the users successfully maintains the SSL session. The customer is migrating to a Cisco Content Engine 560 running version 4.2.1 ACN software.
I understand there are ACN features that could effect the HTTP session persistence/SSL trust. The services/features include boomerang, Reverse Proxy, content balancing. I request information on the service or feature of the ACN that could cause the problem I speak of from above.
I understand there are different methods of implementing session persistence, like sticky session and SSL sticky, but believe the ACN does provide this feature.
Thanks for your reply, but Im afraid that you don't understand my problem. My explanation is sort of vague. I will attempt to outline the problem.
Our customer sits behind a Cisco Content Engine. One of the features they use is proxy. All of the application users must be authenticated before any requests are proxied. This feature is not believed to be a concern.
Im not quite clear, but I believe another one of the CEs features/services is causing the users browser to access the application from one of the other webservers listed in DNS for the application host.domain combination. This prevents the browser from loading the application, because the login data built at user login and stored within the session object belongs to the initial webserver at user login, not on the second webserver.
By redirecting the user to another one of the webserver, the CE does not appear to be keeping session tied to the initial webserver. The CE must be able to keep the session persistent by redirecting the users to the same webserver the session was build on.
The webservers listed in DNS is not really used for load balancing. If the customer bypasses the CE device or uses one of the four available IP addresses entries in DNS, the user is successful in accessing the application after initial login.
The customer is experiencing network issues when attempting to access our application. The customer is experiencing has been seen with a previous customers that had a similar network devices.
The customer uses a Cisco Content Engine CE-560 with Application and Content Networking Software (ACNS) version 4.2.1. The problem seems to a result of the ACNS resolving the hostname.domain.com twice. The webserver's DNS (hostname.domain.com) entry resolves to one of four available webservers (DNS round robining).
webserver1 webserver2 webserver3 webserver4
webserver2 webserver3 webserver4 webserver1
and so on.
All client/webserver communication is through SSL. When the customer uses the FQDN URL (https://hostname.domain.com/webapp/index.jsp) to access the application login page, the server portion of the URL is resolved to webserver1. At this time, the customer has an established HTTPS session with webserver1. Once a login servlet running on webserver1, receives the customer supplied login credentials, the servlet sends a server response 302 redirecting the customer to the selected application.
This redirection response seems to cause the ACNS to resolve the hostname.domain.com and as a result, the customer's browser is redirected to a different webserver, webserver2. The users previous session is no longer valid, causing the application to generate a false inactivity timeout.
If the customer sends a HTTPS request using anyone of the four IP address from DNS, the session is maintained and the customer does not receive the false inactivity timeout, because the session is not "broken".
The customer is migrating off of a Netscape (iPlanet) Web Proxy solution and does not experience the problem accessing the application, using the FQDN URL.
Introduction This article will help you understand the steps on how to
download the UCS licenses from the Cisco Systems website and then
installing it on the UCS. The redacted (blue lines) just covers up
certain numbers for privacy please do not take them...
Introduction This article will help you understand and educate the
customer on how to clear their "expired licenses"
(license-graceperiod-expired) from their UCS-M. If a customer just
purchased a license and needs a step by step guide on how to download
==================== VIC FNIC driver does not support Virtual Volumes (
second level LUN ID ) An enhancement request has been created to track
this feature - CSCux64473 UPDATE - 12-14-2016 We made some traction on
the enhancement request - The Fix is in t...