VIP 1 = 10.10.20.15 80 ( Real Servers 192.168.10.45 and 192.168.10.55 listing on port 80 )
VIP 2 = 10.10.20.15 443 ( Real Servers 192.168.10.45 and 192.168.10.55 listing on port 443 )
I would like to maintain stickness across these two VIPs. Is this possible?
For example: User is using a web browsers and types http://10.10.20.15 the user is directed to VIP 10.10.20.15 80 and then to real 192.168.10.55:80 (based on the predictor method) After browing a few http pages, there is a re-direct on the http page to https://10.10.20.15/idbi/index.htm
My understanding is that the browser sends a new request to VIP 10.10.20.15 443 and there is a 50-50 chance that the connection comes back to the 192.168.10.55:443
How can i ensure that the https connection comes back to the same server?
My guess is, that because you have two class'es that matches incoming traffic, two sticky-configs and two serverfarms, any subsequent traffic that is matchet against a different class, will be re-loadbalanced towards a different serverfarm. And different stickies will be applied to the https-portion of the flow.
Since you're not translating the dst.port for your traffic, one serverfarm and one sticky-config should be sufficient. I've done this myself for traffic, for which I'm not translating the dst.port and it works fine. Basically, you remove the port parameter and simply configure the ip-address of your rservers, as shown below:
Then, use the same stickyconfig in both your classes under your multi-match policy. If this doesn't do the trick, plz let me know. Another option would be cookie-based stickyness, although there's a few more things that has to be considered. I would probably use the 'both' parameter in sticky-config, as the sticky would be based on both the src. and dst. address.
The 'browser expire' is optional, but simply allows for the browser to determine the expiration of the cookie.
ACE assign a unique cookie-value for each of your rservers by calculating a hashed value based on the rserver ip.addr and port and inserts that value into the database. You can display the content of the database with 'sh sticky cookie-insert group sticky-group-id. The result would be something like this:
This value is inserted into the http-header of the clients request and used for stickyness. However, unless you configure 'persistence rebalance', the ACE will only loadbalance based on the first request. Any subsequent requests will simply be packet-switched to the same rserver, until the end-of-flow or the rserver is taken out of rotation/fails. If you need to inspect your http-header at each request, you need to configure an http-parameter-map with persistence-rebalance.
Additionally, you can assign your own cookie values, rather than using a hashed value. Simply configure the following under your sticky-config:
Topology & Design:
Two ACI fabrics
Stretching VLANs using OTV
Both fabrics are advertising BD subnets into same routing domain
Some BDs(or say VLANs) are stretched, but some are not.
Endpoints can move betwee...
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
Topology &Design:Traffic flow within same fabric:Endpoint moves to Fabric-2Bounce Entry Times OutTraffic Black-holedSummarySolutionAppendix:
In the Previous articles of ACI Automation, we are using Postman/Newman a...