CSS VIP with non HTTP and HTTP services

Unanswered Question
Dec 3rd, 2009

Hi there,

I have an application that makes a connection to the server on port 4000.  When the application connects, it also initiates a request on port 80 to check a webserver for updates to the application.  I'm trying to see if I can combine the application connection and the webserver check to use the same VIP and port and have the CSS determine when the connection is a non-web connection to port 4000, or when there is an HTTP request.

Can anyone tell me if this is even possible?

I've tried this configuration, which does work for the HTTP connection, but it doesn't seem to let the non-http connection through:

service RR1  (The application server)
  ip address 10.2.0.101
  port 4000
  protocol tcp
  keepalive type tcp
  keepalive port 4000
  active

service TestHTML (The webserver)

  port 80
  protocol tcp
  ip address 10.2.0.31
  active

owner L3_Owner

  content L3_Rule
    vip address 10.2.10.200
    protocol tcp
    port 4000
    add service RR1

    active

  content L3_Rules_HTTP
    vip address 10.2.10.200
    add service TestHTML
    protocol tcp
    port 4000
    url "/menu.xml"
    active

group QAServers
  add destination service TestHTML
  add destination service RR1
  vip address 10.2.10.200
  active

Note: I'm suing groups because my services are in the same subnet as my VIP addresses ... not ideal, but it has worked in the past when I've been testing out other setups.

Thanks in advance,

Brandon

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4 (1 ratings)
Loading.
jason.espino Thu, 12/03/2009 - 15:32

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

branfarm1 Thu, 12/03/2009 - 16:31

Jason,

Thanks for the reply.   Right now this is more of a proof-of-concept than anything else.  The way my application works now, when the user opens the application (stand-alone desktop app) it makes a connection to our webserver on port 80 and checks the contents of a file that contains version information.  Once the version check has completed, a new connection is initiated to port 4000 on our application server.

I'm trying to configure it so that all connections are to the same IP:port, leaving the CSS to direct the connection to the appropriate resource -- version check goes to the Web server, and the application connection goes to the app server.  I should also clarify that the first connection is a quick one -- grab the version file and you're done.  The connection to the app server is a long-term TCP connection for server-app traffic.

I've verified that both services pass the keep-alive check and show as Alive in the service summary.   I tried adding the "no persistent" command to my content rules, but that didn't seem to change anything.  As it stands now, I can point my browser to the VIP address on port 4000 and request menu.xml and it works, but pointing the application at the VIP address (port 4000) does not.  If I suspend the L3_Rules_HTTP content rule, then my application connection works properly.

--Brandon

Actions

This Discussion