05-16-2008 08:13 AM
We have a set of vservers on a CSM running 4.2.5. The TCP port 80 rule sends the request to a serverfarm with a vserver-redirect to force the request to use TCP port 443. There is a second vserver for TCP port 443 that accepts the redirect and forwards to the SSL module.
The problem is that when an extra long url is sent the CSM never replies from the request to TCP port 80 (we see the syn, syn-ack, ack, then several tries from the client using the GET verb (all others are TCP restransmissions - no ACKs from the CSM or server).
If we send the same request directly to the vserver on TCP port 443 it works fine. Can you give us insight as to what we might be able to do? Thanks in advance.
05-16-2008 10:07 AM
http parse length problem.
Increase it with the command :
gdufour-cat6k-2(config-slb-vserver)#parse-length ?
<1-4000> maximum number of bytes to parse
default-policy set default policy when maximum parse length is reached for a
session
Gilles.
05-16-2008 10:43 AM
Thanks for your quick reply!
I looked at the request with an HTTP sniffer and see that it is 2277 bytes. I changed the vserver that is its destination using the parse-length command to 4000 bytes (max), but it is still hanging. I will do some more testing, but is it possible that maybe the redirect serverfarm is having the problem? I never see the 302 redirect take place with this length of request, however shorter requests work fine.
05-16-2008 11:41 AM
gdufour-cat6k-2#sho mod csm 3 tech proc 4 | i parse
LB Rjct: L7 max parse len 0
LB Rjct: L7 parser 0
gdufour-cat6k-2#
If these counters are still increasing, you did not solve the problem of header length.
The default is 2000 bytes, so 2277 is above it and would clearly result in no response.
Increasing the parse length should work.
Gilles.
05-16-2008 11:55 AM
Must be something else...I do not see that counter incrementing. See the output below (I had my browser trying to open the url during this time). Also notice details on the vserver that is its destination. max parse len = 12000 (is this bytes or bits?).
% Unrecognized command
bvldclbrtr1#sho mod csm 1 tech pro
bvldclbrtr1#sho mod csm 1 tech proc 4 | in
bvldclbrtr1#sho mod csm 1 tech proc 4 | include parse
LB Rjct: L7 max parse len 5 (5)
LB Rjct: L7 parser 0
bvldclbrtr1#sho mod csm 1 tech proc 4 | include parse
LB Rjct: L7 max parse len 5
LB Rjct: L7 parser 0
bvldclbrtr1#sho mod csm 1 tech proc 4 | include parse
LB Rjct: L7 max parse len 5
LB Rjct: L7 parser 0
bvldclbrtr1#sho mod csm 1 tech proc 4 | include parse
LB Rjct: L7 max parse len 5
LB Rjct: L7 parser 0
bvldclbrtr1#sho mod csm 1 tech proc 4 | include parse
LB Rjct: L7 max parse len 5
LB Rjct: L7 parser 0
bvldclbrtr1#sho mod csm 1 tech proc 4 | include parse
LB Rjct: L7 max parse len 5
LB Rjct: L7 parser 0
bvldclbrtr1#sho mod csm 1 tech proc 4 | include parse
LB Rjct: L7 max parse len 5
LB Rjct: L7 parser 0
bvldclbrtr1#sho mod csm 1 tech proc 4 | include parse
LB Rjct: L7 max parse len 5
LB Rjct: L7 parser 0
bvldclbrtr1#sho mod csm 1 tech proc 4 | include parse
LB Rjct: L7 max parse len 5
LB Rjct: L7 parser 0
bvldclbrtr1#sho mod csm 1 tech proc 4 | include parse
LB Rjct: L7 max parse len 5
LB Rjct: L7 parser 0
bvldclbrtr1#sho mod csm 1 tech proc 4 | include parse
LB Rjct: L7 max parse len 5
LB Rjct: L7 parser 0
bvldclbrtr1#sho mod csm 1 vser
bvldclbrtr1#sho mod csm 1 vservers name ITS-T detail
ITS-T, type = SLB, state = OPERATIONAL, v_index = 527
virtual = 158.139.218.77/32:80 bidir, TCP, service = NONE, advertise = FALSE
idle = 3600, replicate csrp = none, vlan = 218, pending = 30, layer 4
max parse len = 12000, persist rebalance = TRUE
ssl sticky offset = 0, length = 32
conns = 0, total conns = 64
Default policy:
server farm = R-ITS-T, backup =
sticky: timer = 0, subnet = 0.0.0.0, group id = 0
Policy Tot matches Client pkts Server pkts
-----------------------------------------------------
(default) 64 1069 871
bvldclbrtr1#
05-17-2008 05:32 AM
what version do you run ?
Could you show the current config ?
Can you sniff the traffic from the CSM portchannel when connecting from the client ?
Is this counter increasing when you connect from the client :
(default) 64 1069 871
??
Gilles.
05-22-2008 05:06 AM
We are running version 4.2.5. I will get a sniff of the traffic on port channel 257 for you. No the counter that you had me check for is not increasing when I connect as a client. Below is the current configuration:
serverfarm R-ITS-T
nat server
no nat client
redirect-vserver R-ITS-T
webhost relocation its-t.conocophillips.net/%p
ssl 443
idle 120
inservice
!
vserver ITS-T
virtual 10.12.120.77 tcp www
vlan 218
serverfarm R-ITS-T
persistent rebalance
parse-length 4000
inservice
!
vserver ITS-T-SSL
virtual 10.12.120.77 tcp https
serverfarm SSL-MODULE2
persistent rebalance
inservice
!
vserver ITS-T-V4
virtual 10.12.120.77 tcp www
vlan 4
serverfarm BVLWBIT184
persistent rebalance
inservice
The url that is trying to be sent is below (which works fine if we send it to vserver ITS-T-SSL on port 443). It is on the redirect that is failing:
05-22-2008 07:50 AM
I tested your config with 4.2(8) and it works fine.
We had to change the rediret code due to ddts CSCse98829: %p in redirect doesn't work for small GETs which was integrated with 4.2.6
This change may have solved a problem with long url that had not been detected.
You can try an upgrade to 4.2.9 to see if that solves your problem.
Gilles.
05-22-2008 09:49 AM
I upgraded our CSM in our lab environment with 4.2.9. This did not fix the problem. It still appears that the url can be cut down to around 1850 bytes and the CSM will reply with the redirect. But the one that is posted here shows up to be 2277 bytes and it never gets a redirect. I am currently waiting on our TCOM guys (I am a web guy) to get their sniffer set up so I can get a capture file. Hope to post this up this afternoon. Thanks for all of your suggestions and help so far.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide