Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

CSS11501 Slow per connection performance

I'm seeing an issue with our CSS 11501 (SW vers units where the per-connection (flow?) throughput is very slow. It appears to be capped around 100kBps.

CSS port 1 has an internet uplink on n.n.n.1. The CSS vlan IP is n.n.n.2/27 (via circuit vlan 1065).

The servers are plugged directly into the CSS. They are in the same vlan and ip space, ie. n.n.n.13, with default gateway n.n.n.1.

My issue is that an individual http download, whether coming to/from one of the servers behind the CSS, is getting very poor throughput. Each http "flow" seems to be capped at 100Kbps or less.

Can anyone point out why this is happening and how I might resolve/avoid the issue?

Cisco Employee

Re: CSS11501 Slow per connection performance

could you first check if the problem exist or not when bypassing the CSS.

Are you going directly to the server via the CSS or do you hit first a content rule and the CSS loadbalances the connection to a server ?

If loadbalancing, the type of content rule is very important, so we will need a copy of it.

Also, capture a trace on the server and the client [simultaneous] to see where there could be inter-packet delay.


New Member

Re: CSS11501 Slow per connection performance

There is no throughput problem if the CSS is bypassed, ie, the server is connected directly to the same switch as the firewall, and has it's default route set to the gateway ip address of the firewall. I can pull the full 100Mbit/s FD in this configuration, but the CSS doesn't see the traffic, so no load-balancing.

The network layout has changed slightly since my first posting, but I'm still seeing a throughput issue for the devices connected/routing out via the CSS.

I have now also raised this with Cisco TAC.


Outside LAN -- LAN1/28


usage: firewall public vip and Internet


Inside LAN -- LAN2/27


usage: firewall inside vip

CSS LAN2 vip (redundant-interface)

CSS content vips (redundant-vip)

CSS01 LAN2 interface address

CSS02 LAN2 interface address


Server LAN -- LAN3/28


usage: CSS LAN2 vip

App Servers

DB Servers

Admin Servers

CSS01 LAN3 interface address

CSS02 LAN3 interface address


The servers (services) are defined like this :

service web01

redundant-index 1

port 80

protocol tcp

keepalive type tcp

keepalive port 80

ip address LAN3.35


service web02

redundant-index 2

port 80

protocol tcp

keepalive type tcp

ip address LAN3.36


Load-balanced vips (content) are defined like this :

content website

protocol tcp

vip address LAN2.11

port 80

sticky-inact-timeout 60


add service web01

add service web02

redundant-index 101

advanced-balance sticky-srcip


LAN1, LAN2, and LAN3 are all publicly accessible Internet addresses (subject to the firewall placed between LAN 1&2). NAT is not used.

Any thoughts about why a single connection (flow) is slowed down dramatically when talking to either the servers that are placed in LAN3, or the VIPs placed in LAN2.


Cisco Employee

Re: CSS11501 Slow per connection performance

I have the same setup in the lab and have no issue.

We will need a simultaneous sniffer trace on client and server.

Also, what is your CSS software version ?


New Member

Re: CSS11501 Slow per connection performance


I didn't notice your reply coming in, apologies for the delayed response.

I managed to find some time yesterday to take a fresh look at the problem, and was able to resolve my issue.

The problem was not with the CSS afterall. The operating system was bringing the network card up as 100Mbit Half Duplex, despite us telling it to use 100FD.

I had to reset everything to Autonegotiate to get it all running as 100FD. I'm now able to pull data across the CSS at the full 100Mbit/s speed (10MB/s).

Thanks for helping look into this.