Reaching into history here asking about a Cisco CSS however we have a customer with a CSS 11501 that has a SSL module that we're trying to do some L5 rules over SSL with.
The rules work fine over HTTP but when I wrap them in SSL (the SSL is terminated on the CSS) it does not work.
We have a backend server running IIS on port 80 and a different web server on port 8080 (eg. tomcat).
What needs to happen is that a client hits the website and the if the URL has /follow-me/ in it, then the connection needs to go to port 8080 on the backend server. This works fine over HTTP. When we try the same with HTTPS what we see (in the IE and Google Developer tools) is a 404 come back from IIS so it looks like the CSS is not processing the L5 rules?
Just to confuse matters - if we hit the "/follow-me/" URL directly in a web-browser it appears to go to the tomcat webserver on backend port 8080, however after that all requests (from that browser) go to the tomcat on port 8080.
Alternatively if we hit the normal webpage first and then try to access "/follow-me/" we are presented with the IIS 404 page.
So somehow the SSL session is "sticking" and not processing the L5 rules?
Problem is related to the layer 5 behavior when it comes to HTTP 1.1. The config seems to be in good shape and I'm almost sure the persistence reset remap command should get this on the right track.
(config)# persistence reset remap
You may want to add the no persistent command under both clear text content rules.
Basically with L5 and default persistence the CSS will verify only the first match after the 3-way-handshake and all subsequent request won't be inspected to look for a more specific match this helps to speed up the L5 process.
Thanks for your feedback, I tried your suggestions but they didn't appear to make any difference.
To confuse matters greatly, the connection(s) and L5 processing works fine from Firefox / Opera / Safari - but does not work successfully from IE (8 / 9) or Chrome. Argh.
The original statement above about confusing matters is only applicable to Chrome - in IE if you go to the "/follow-me/" URL the tomcat responds correctly but when accessing "/follow-me" via the main webpage the 404 that is returned is from IIS.
In general, Pablo's comments are right. However, the right command to be added to the content rule configuration is "no persistent". This will force the CSS to look at all the requests inside the same TCP flow and make a separate load-balancing decision for each of them.
Thank you for the clarification Daniel. Alas I have implemented those commands and still the issue persists. For the moment we have been requested to hold off whilst the Developer works on a 'work-around' for this issue.
The above comments are absolutely correct, you need the "no persistent" in *ALL* of your HTTP rules (if even one of them is missing it, the connection will become stuck there), and you also must have "persistence reset remap" set.
Sounds like you've already done that, so I think you may have run into the same problem we were just facing, especially if it only happens on some browsers and everything works great if it's via HTTP instead of HTTPS. I just posted a solution:
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...