In my lab I have CISCO 11500 series Load Balancer (Context Services Switches)and using layer 5 URl based algorithm. Anyhelp on this would be very great full to you.
Please find below the service and content configuration;-
ip address 10.20.8.100
keepalive frequency 15
keepalive retryperiod 3
keepalive maxfailure 5
keepalive type script cmg_http_script "10.20.8.100 /keepalive 20042"
vip address 10.20.8.97
add service server1
Client sends HTTP POST cmd to the CSS VIP IP and for which the payload is larger that 1460, the CSS resets(RST) the connection right after acknowledging the full payload.Packet 12
Transmission Control Protocol, Src Port: 20042 (20042), Dst Port: 52789 (52789), Seq: 8098765, Ack: 2387902, Len: 0
Packet 13 RST packet sent from LB to the client(---->RST packt been send back to client by CSS were it needs to expect the next segment from the client).
hence the CSS will not forward the connection over to the servers.
I am running the latest firmware on the CSS. IS theer anything which I need to configure on the CSS?
Thanks in advance.
Hi Fariha ,
Firstly you have to know how much is the max data you can send thru your infra-structure, un-fragmented.
Try pinging to the website you are trying to get to, first with a high packet size, reducing the packet size until you get a response.
ping x.x.x.x -l 1450 -f
ping x.x.x.x -l 1440 -f
ping x.x.x.x -l 1430 -f
and so on until you get a response. The number you find is what you should set the MSS (Maximum Segment Size ) to.
If it is IP fragmentation issue then one of the soultion would be configuring TCP MSS. The TCP Maximum Segment Size (MSS) defines the maximum amount of data that a host is willing to accept in a single TCP/IP datagram. This TCP/IP datagram may be fragmented at the IP layer. The MSS value is sent as a TCP header option only in TCP SYN segments. Each side of a TCP connection reports its MSS value to the other side. Contrary to popular belief, the MSS value is not negotiated between hosts. The sending host is required to limit the size of data in a single TCP segment to a value less than or equal to the MSS reported by the receiving host.
I think you need to configure TCP Maximum Segment Size (MSS).
Use the flow tcp-mss command to configure the TCP maximum segment size (MSS) that the CSS expects to receive from the transmitting device.
The MSS is the largest amount of TCP data that can be transmitted in one segment.
The need for a smaller MSS between devices may be necessary in rare instances due to network restrictions between devices.
The flow tcp-mss command changes the MSS value in the TCP header OPTIONS field of a SYN segment, to reduce the MSS from the default value of 1460 bytes.
The flow tcp-mss command applies only when the client is accessing a Layer 5 content rule as you said in your case its a layer 5 load balancing.
Please be informed that the CSS does not negotiate TCP maximum segment size for Layer 3 or Layer 4 content rules.
Enter a maximum segment size (in bytes) from 1 to 1460.
The default is 1460 bytes.
Use the no form of the command to reset the TCP maximum segment size back to the default value of 1460 bytes.
Caution Do not define a smaller than necessary TCP maximum segment size with the flow tcp-mss command.
Smaller payloads may be less efficient due to increased overhead.
To configure a TCP maximum segment size of 1400 bytes, enter:
(config)# flow tcp-mss 1400
To reset the TCP maximum segment size to the default value of 1460 bytes, enter:
(config)# no flow tcp-mss
Hope it will help. If you still find its not solving your issue please write back to me.
Message was edited by: sachinga.hcl
Your content rule Fazain as shown in your post is a L3 rule.
The CSS will only look into the SYN to make its loadbalancing decision.
Therefore, it won't send a RST normally.
Are you sure this is not the server sending the RST ?
Do you have a simultanous trace on client and server ?
Could you share those with us.
RST packet been send from CSS to the client. I did some reserach and found couple of bugs but I dont think thats is causing this as I am upgraded to the latest firmware which is resolved those bugs.
I found some strange behaviour now:-
1) Client send packet to CSS
2) CSS acknowledge it same happens for 2 packets after which
3) Client sent FIN,PSH,ACK packet to CSS after which CSS ack with RST packet.
Wahts is causing this? Thanks in advance.
Get me the complete configuration and the sniffer trace in front and back of the CSS.
As I said, for L3 rule just like you configured, the CSS only looks at the first packet and then just ignore what is going on between client and server.
The problem is the FIN.
The client sends all the data and with the last piece of data there is a FIN.
This tells the server the client is done sending and it wants to close the connection.
A normal server would just read the request, send a response and then close the connection.
But the CSS does not like FIN when it is in spoof mode and still has not decided which server to use.
This is why it does ACK receiving the FIN and immediately sends a RST.
As far as I know this is the way the CSS works.
Could you change the client to wait for the response before closing the connection ?
Thanks for the update.
Is there anything which can be disable on the CSS so that clients stays on with the same session with the server rather than client send out the FIN flag to CSS? Will configuring
As Bcz everything works fine untill the client sends the FIN flag to CSS and not sure what to be turned off on the servers.
Thanks in advance.
There is unfortunately nothing you can do on the CSS.
This a known limitation.
You can remove all HTTP parsing from the CSS (no more url parsing, or cookie insertion).
This will change the rule from L5 to L4 and this would work.
But again you lose all the parsing functionalities.
What do you mean by Well known limitation is this recorded in any release notes or is it a bug? will this issue be solved anytime(i.e i mean to say in any upcoming latest firmware?
Thanks in advance.
This is a corner case that we didn't expect during implementation of the CSS code.
Unfortunately this can't be changed without completely rewriting a big portion of the CSS code and design.
Therefore it was decided to leave it like this.