Hello Brandon,
Your configuration should work just fine when it comes to connections destined to the application port 4000. With the existing content rules in place normal HTTP traffic will not get processed as there is no port 80 rule. You do however, have NAT rules in place on the services that will allow the CSS to re-write the destintation port to 80 or 4000 depending on what service the client's connection lands on. If there is no string present within the URL when the client uses the application then their connection should fall on the following content rule and service.
content L3_Rule
vip address 10.2.10.200
protocol tcp
port 4000
add service RR1
active
service RR1 (The application server)
ip address 10.2.0.101
port 4000
protocol tcp
keepalive type tcp
keepalive port 4000
active
The only time this rule will get used is the client must have the "/menu.xml" string present within the inbound URL over port 4000 for the CSS to forward their connection to this rule and service.
content L3_Rules_HTTP
vip address 10.2.10.200
add service TestHTML
protocol tcp
port 4000
url "/menu.xml"
active
service TestHTML (The webserver)
port 80
protocol tcp
ip address 10.2.0.31
active
The moment their connection lands on this rule the CSS will re-write the destination port to 80 rather then 4000 and present the connection to the destination server(webserver).
As far as what are you trying to accomplish I'm not sure how that application works, but the moment a client connects with the application is the port 80 check performed as a completely new connection/check? Is the port 80 check against the server's IP or the VIP address?
Also have you verified both services passed their keep-alive check? This will let you know if the application server can accept TCP connections over TCP port 4000. Please be advised, the CSS is performing the default ICMP check for the webserver's keep-alive due to it's current configuration. Simply adding "keepalive type tcp" to it's configuration will change the keep-alive check to perform a TCP connection over port 80.
Another thing I would consider is removing content persistence on your content rules since you have introduced a layer 7 content rule. Enter the "no persistent" command on the 2 content rules. Content persistance allows the CSS to balance upon the inital GET of the client's request regardless if the second GET matches the same content rule or not. The moment you introduce a layer 7 rule such as the "/menu.xml" URL content rule it would be best to remove content persistance and allow the CSS to rebalance the client's connection to a more specific content rule if needed. That is were the "persistance reset remap" or "redirect" come into play as to how the CSS will move the connection.
Are the connections destined for this VIP using the application coming from servers within the same Circuit VLAN? Internal load balancing? The only time the Group Rule you configured is needed is if you need to SNAT the client traffic.
I hope this info helps!
- Jason
