cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
773
Views
0
Helpful
8
Replies

CSM redirect - header length

aanelso1
Level 1
Level 1

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.

8 Replies 8

Gilles Dufour
Cisco Employee
Cisco Employee

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.

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.

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.

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#

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.

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:

http://its-t.conocophillips.net/sap/bc/bsp/sap/z_ext_resp/default.htm?WI=000101281590&OBT=ZEPAYINVST&OBK=2008042510064100108846WRMATHE&RSP=2&MSC=00001-00002-00003-00004-00005-00006-00007-00008-00009-00010-00011-00012-00013-00014-00015-00016-00017-000...

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.

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.

Review Cisco Networking for a $25 gift card