cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1851
Views
0
Helpful
3
Replies

ACE 4710 one-arm L4 load balancing removes accept-encoding?

sokarlsson
Level 1
Level 1

We have built a simple one-arm PAT config to round robin load balance two Varnish servers. In the "Default L7 load-balancing action" we have left compression to "N/A". It looks like the ACE removes "Accept-Encoding: gzip, deflate" from the client header.

Is this normal behaviour? We would like the Varnish to do the compression. Do we need modify the headers to get this through the ACE?

3 Replies 3

Kanwaljeet Singh
Cisco Employee
Cisco Employee

Hi,

Yes this does seem to be the behavior. Please read below:

HTTP compression is a capability built into web servers and web browsers to improve site performance by reducing the amount of time required to transfer data between the server and the client. Performing compression on the ACE offloads that work from the server, thereby freeing up the server to provide other services to clients and helping to maintain fast server response times.

When you enable HTTP compression on the ACE, the appliance overwrites the client request with "Accept-Encoding identity" and turns off compression on the server-side connection. HTTP compression reduces the bandwidth associated with a web content transfer from the ACE to the client.

So ACE rewrites the ACCEPT-ENCODING header to IDENTITY to indicate to the server that it should not compress the return data. That would be done by ACE.

Also, default method is used when client comes with both gzip or deflate for "ACCEPT ENCODING". For compression to work, a client must send a request with an ACCEPT-ENCODING method of gzip or deflate. If a client sends both methods, then the ACE uses the configured method(default method).

Also, you can see if ACE is compressing the packets or in "show service-policy detail.

switch/Admin#

show service-policy L7_COMP_SLB_POLICY detail

Status     : ACTIVE

Description: -----------------------------------------

Interface: vlan 1 108

  service-policy: L7_COMP_SLB_POLICY

    class: vip

     VIP Address:    Protocol:  Port:

     2.0.5.1         tcp        eq    80

      loadbalance:

        L7 loadbalance policy: pm

        VIP ICMP Reply       : ENABLED

        VIP state: OUTOFSERVICE

        Persistence Rebalance: ENABLED

        curr conns       : 0         , hit count        : 0

        dropped conns    : 0

        client pkt count : 0         , client byte count: 0

        server pkt count : 0         , server byte count: 0

        conn-rate-limit      : 0         , drop-count : 0

        bandwidth-rate-limit : 0         , drop-count : 0

        L7 Loadbalance policy : pm

          class/match : h

            ssl-proxy client : c

            LB action :

               primary serverfarm: sf1

                    state: DOWN

                backup serverfarm : -

            hit count        : 0

            dropped conns    : 0

            compression      : on  <------------------------------ Compression is enabled if the value is "on"

compression  bytes_in  : 0       bytes_out : 0  <--- Number of bytes transmitted after compressing the server response

Compression ratio : 0.00%  <------------------------------ Percentage of data compressed

Gzip: 0               Deflate: 0  <--------------- Number of times the method is used

compression errors:                                     _

User-Agent  : 0               Accept-Encoding    : 0   |

Content size: 0               Content type       : 0   |

Not HTTP 1.1: 0               HTTP response error: 0   |-- Check these error counters to see if they are increasing

Let me know if you have any questions.

Regards,

Kanwal

Probably true if you enable compression but we have not.

After capturing some traffic I concluded that the ACE surely had NOT rewritten the headers. Request headers - all the way from client, through ACE and Varnish servers - still had "Accept-Encoding: gzip, deflate" unaltered.

In some cases though the IIS that delivers the html data decides to compress the data, in some cases it simply refuse.

In all tests we have done the request contains "Accept-Encoding: gzip, deflate" so it's at the IIS that is the problem here.

Thanks anyway Kanwal for clarifying.

Hi,

Yeah without compression ACE shall not touch the "Accept Encoding" Header.

Regards,

Kanwal