Usually session timeouts is global value per device.
It should not be specified per listener.
Regards,
-Sam.
On 2 במאי 2014, at 05:32, "Carlos Garza"
<carlos.ga...@rackspace.com<mailto:carlos.ga...@rackspace.com>> wrote:
our stingray nodes don't allow you to specify. Its just an enable or disable
option.
On May 1, 2014, at 7:35 PM, Stephen Balukoff
<sbaluk...@bluebox.net<mailto:sbaluk...@bluebox.net>>
wrote:
Question for those of you using the SSL session ID for persistency: About how
long do you typically set these sessions to persist?
Also, I think this is a cool way to handle this kind of persistence
efficiency-- I'd never seen it done that way before, eh!
It should also almost go without saying that of course in the case where the
SSL session is not terminated on the load balancer, you can't do anything else
with the content (like insert X-Forwarded-For headers or do anything else that
has to do with L7).
Stephen
On Wed, Apr 30, 2014 at 9:39 AM, Samuel Bercovici
<samu...@radware.com<mailto:samu...@radware.com>> wrote:
Hi,
As stated, this could either be handled by SSL session ID persistency or by SSL
termination and using cookie based persistency options.
If there is no need to inspect the content hence to terminate the SSL
connection on the load balancer for this sake, than using SSL session ID based
persistency is obviously a much more efficient way.
The reference to source client IP changing was to negate the use of source IP
as the stickiness algorithm.
-Sam.
From: Trevor Vardeman
[mailto:trevor.varde...@rackspace.com<mailto:trevor.varde...@rackspace.com>]
Sent: Thursday, April 24, 2014 7:26 PM
To: openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>
Subject: [openstack-dev] [Neutron][LBaaS] Use Case Question
Hey,
I'm looking through the use-cases doc for review, and I'm confused about one of
them. I'm familiar with HTTP cookie based session persistence, but to satisfy
secure-traffic for this case would there be decryption of content, injection of
the cookie, and then re-encryption? Is there another session persistence type
that solves this issue already? I'm copying the doc link and the use case
specifically; not sure if the document order would change so I thought it would
be easiest to include both :)
Use Cases:
https://docs.google.com/document/d/1Ewl95yxAMq2fO0Z6Dz6fL-w2FScERQXQR1-mXuSINis
Specific Use Case: A project-user wants to make his secured web based
application (HTTPS) highly available. He has n VMs deployed on the same private
subnet/network. Each VM is installed with a web server (ex: apache) and
content. The application requires that a transaction which has started on a
specific VM will continue to run against the same VM. The application is also
available to end-users via smart phones, a case in which the end user IP might
change. The project-user wishes to represent them to the application users as a
web application available via a single IP.
-Trevor Vardeman
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
