Modifying an ssl-proxy-list

Unanswered Question
Jul 23rd, 2008
User Badges:

Hi,


I have 1 ssl-proxy-list with 3 virtual ssl servers defined. I also have the ssl-proxy-list added to several services. I need to add the following to each of the 3 servers:


ssl-server 3 tcp server window 40960

ssl-server 3 tcp virtual window 40960


Sample of existing ssl-proxy-list:


ssl-server 3

ssl-server 3 rsakey DATA-test-su

ssl-server 3 rsacert DATA-test-su

ssl-server 3 vip address 10.1.5.14

ssl-server 3 cipher rsa-with-rc4-128-md5 10.1.5.14 88

ssl-server 3 urlrewrite 3 *

ssl-server 3 ssl-queue-delay 0

ssl-server 3 tcp virtual nagle disable


My questions:


1. When I suspend this list, is it best practice to do "no ssl-proxy-list LIST", modify in a notepad and re-paste or just add to each server ? and then re-activate (active) ?


2. Do the order of the items in list matter, like in an ACL ?


3. Will I require removing and re-adding it to each and every service that has it defined ?


3. Due to the rsakey and rsacert, will this change require a reboot of the CSS ?


Thank you in advance !!!

M

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4 (1 ratings)
Loading.
Syed Iftekhar Ahmed Wed, 07/23/2008 - 16:21
User Badges:
  • Blue, 1500 points or more

If you are running 7.5+ code then its easy


Q1.

1. Suspend ssl-proxy list

2. Make modification to the proxy list

3. Activate proxy-list


Q2. No

Q3. No

Q4. No


Syed

mduhra Thu, 07/24/2008 - 07:41
User Badges:

I have the following, so I should be fine:


CSS11501# sh ver

Version: sg0810106 (08.10.1.06)

Flash (Locked): 08.10.1.06

Flash (Operational): 08.10.1.06

Type: PRIMARY

Licensed Cmd Set(s): Standard Feature Set


mduhra Mon, 07/28/2008 - 07:32
User Badges:

I applied my change, which was to adjust the TCP window using this command set:


ssl-server 1 tcp server window 40960

ssl-server 1 tcp virtual window 40960


However, the CSS doesn't support the 'window' command. So used this instead:


ssl-server 1 tcp buffer-share rx 65536

ssl-server 1 tcp buffer-share tx 65536


My question:


1. Other than "show ssl-proxy-list", are there any other commands that allow you to see the running TCP window/buffer-size ?



mduhra Tue, 07/29/2008 - 10:44
User Badges:

CSS11501# sh ver

Version: sg0810106 (08.10.1.06)

Flash (Locked): 08.10.1.06

Flash (Operational): 08.10.1.06

Type: PRIMARY

Licensed Cmd Set(s): Standard Feature Set


That link is for 8.20, that's likely why it's different.


Is there any other commands to check the running TCP window size or than show ssl-proxy-list ?


Manjit.

Syed Iftekhar Ahmed Tue, 07/29/2008 - 12:09
User Badges:
  • Blue, 1500 points or more

External traces

1.Client to CSS

2.CSS to server


will give you the TCP Window size.


Syed

sachinga.hcl Tue, 07/29/2008 - 22:34
User Badges:
  • Silver, 250 points or more

Hi Manjit ,


I am sending the details of the packet which you can see after packet capturing done at some ethreal or cisco NAM module software for your reference.


In this you will see the output of the packet starting by


either


DLC


or


IP


or


TCP



I have marked the lines as

--------------- > this line is of your interest

for your quick reference.


Kindly find the below :


Server Side Issues

The server may send a null SSL SID.


Frame Status Source Address Dest. Address Size Rel. Time Delta Time Abs. Time Summary

28 [192.168.222.34] [192.168.222.251] 844 0:00:06.769 0.001.114 09/25/2001

05:46:26 PM TCP: D=1272 S=443 ACK=84536369 SEQ=2714661520 LEN=790 WIN=5840

DLC: ----- DLC Header -----

DLC:

DLC: Frame 28 arrived at 17:46:26.7699; frame size is 844 (034C hex) bytes.

DLC: Destination = Station 0010A4A6FE51

DLC: Source = Station 00E01805C3A4

DLC: Ethertype = 0800 (IP)

DLC:

IP: ----- IP Header -----

IP:

IP: Version = 4, header length = 20 bytes

IP: Type of service = 00

IP: 000. .... = routine

IP: ...0 .... = normal delay

IP: .... 0... = normal throughput

IP: .... .0.. = normal reliability

IP: .... ..0. = ECT bit - transport protocol will ignore the CE bit

IP: .... ...0 = CE bit - no congestion

IP: Total length = 830 bytes

IP: Identification = 14832

IP: Flags = 4X

IP: .1.. .... = don't fragment

IP: ..0. .... = last fragment

IP: Fragment offset = 0 bytes

IP: Time to live = 64 seconds/hops

IP: Protocol = 6 (TCP)

IP: Header checksum = BF5A (correct)

IP: Source address = [192.168.222.34]

IP: Destination address = [192.168.222.251]

IP: No options

IP:

TCP: Retransmitted in frame 42

TCP: ----- TCP header -----

TCP:

TCP: Source port = 443 (Https)

TCP: Destination port = 1272

TCP: Sequence number = 2714661520

TCP: Next expected Seq number= 2714662310

TCP: Acknowledgment number = 84536369

TCP: Data offset = 20 bytes

TCP: Flags = 18

TCP: ..0. .... = (No urgent pointer)

TCP: ...1 .... = Acknowledgment

TCP: .... 1... = Push

TCP: .... .0.. = (No reset)

TCP: .... ..0. = (No SYN)

TCP: .... ...0 = (No FIN)



TCP: Window = 5840 --------------- > this line is of your interest




TCP: Checksum = 1717 (correct)

TCP: No TCP options

TCP: [790 Bytes of data]

TCP:



continue to page 2--->

sachinga.hcl Tue, 07/29/2008 - 22:36
User Badges:
  • Silver, 250 points or more

Page 2 --- >


Client Side Issues

Internet Explorer (IE) 5.0/5.5 SSL SID changes approximately every two minutes.


The client will see different behavior with IE 5.x than with Netscape. IE will cause the client to change its SSL ID every two minutes and this will break stickyness with application SSL and advanced-balance SSL, as this is L5 stickyness based on SSL SID. A sniffer trace from the client will show the ID field change.


In this frame, starting at offset hex 62 for the length and offset 63 for the first byte of the SSL ID, you can see values of 20 and 29 respectively.


- - - - - - - - - - - - - - - - - - - - Frame 28 - - - - - - - - - - - - - - - - - - - -

Frame Status Source Address Dest. Address Size Rel. Time Delta Time Abs. Time Summary

28 [161.44.175.145] [208.184.140.161] 150 0:00:03.371 0.016.261 10/19/2001 03:57:37 PM

TCP: D=443 S=3406 ACK=121147614 SEQ=105456165 LEN=96 WIN=9520

----- DLC Header -----

DLC:

DLC:

DLC: Frame 28 arrived at 15:57:37.3792; frame size is 150 (0096 hex) bytes.

DLC: Destination = Station Cisco107AC01

DLC: Source = Station Xircm2229D27

DLC: Ethertype = 0800 (IP)

DLC:

----- IP Header -----

IP:

IP:

IP: Version = 4, header length = 20 bytes

IP: Type of service = 00

IP: 000. .... = routine

IP: ...0 .... = normal delay

IP: .... 0... = normal throughput

IP: .... .0.. = normal reliability

IP: .... ..0. = ECT bit - transport protocol will ignore the CE bit

IP: .... ...0 = CE bit - no congestion

IP: Total length = 136 bytes

IP: Identification = 35210

IP: Flags = 4X

IP: .1.. .... = don't fragment

IP: ..0. .... = last fragment

IP: Fragment offset = 0 bytes

IP: Time to live = 128 seconds/hops

IP: Protocol = 6 (TCP)

IP: Header checksum = C2CD (correct)

IP: Source address = [161.44.175.145]

IP: Destination address = [208.184.140.161]

IP: No options

IP:

----- TCP header -----

TCP:

TCP:

TCP: Source port = 3406

TCP: Destination port = 443 (Https)

TCP: Sequence number = 105456165

TCP: Next expected Seq number= 105456261

TCP: Acknowledgment number = 121147614

TCP: Data offset = 20 bytes

TCP: Flags = 18

TCP: ..0. .... = (No urgent pointer)

TCP: ...1 .... = Acknowledgment

TCP: .... 1... = Push

TCP: .... .0.. = (No reset)

TCP: .... ..0. = (No SYN)

TCP: .... ...0 = (No FIN)


TCP: Window = 9520 --------------- > this line is of your interest



TCP: Checksum = 9A67 (correct)

TCP: No TCP options

TCP: [96 Bytes of data]

TCP:


sachinga.hcl Tue, 07/29/2008 - 22:36
User Badges:
  • Silver, 250 points or more

The frame below, sent by the client 2 minutes and 64 seconds later, has values of 40 and 01 for the same fields.


- - - - - - - - - - - - - - - - - - - - Frame 945 - - - - - - - - - - - - - - - - - - - -

Frame Status Source Address Dest. Address Size Rel. Time Delta Time Abs. Time Summary

945 [161.44.175.145] [208.184.140.161] 153 0:02:35.533 0.001.228 10/19/2001 04:00:09

PM TCP: D=443 S=3464 ACK=1374357434 SEQ=105608315 LEN=99 WIN=9520

----- DLC Header -----

DLC:

DLC:

DLC: Frame 945 arrived at 16:00:09.5404; frame size is 153 (0099 hex) bytes.

DLC: Destination = Station Cisco107AC01

DLC: Source = Station Xircm2229D27

DLC: Ethertype = 0800 (IP)

DLC:

----- IP Header -----

IP:

IP:

IP: Version = 4, header length = 20 bytes

IP: Type of service = 00

IP: 000. .... = routine

IP: ...0 .... = normal delay

IP: .... 0... = normal throughput

IP: .... .0.. = normal reliability

IP: .... ..0. = ECT bit - transport protocol will ignore the CE bit

IP: .... ...0 = CE bit - no congestion

IP: Total length = 139 bytes

IP: Identification = 63628

IP: Flags = 4X

IP: .1.. .... = don't fragment

IP: ..0. .... = last fragment

IP: Fragment offset = 0 bytes

IP: Time to live = 128 seconds/hops

IP: Protocol = 6 (TCP)

IP: Header checksum = 53C8 (correct)

IP: Source address = [161.44.175.145]

IP: Destination address = [208.184.140.161]

IP: No options

IP:

----- TCP header -----

TCP:

TCP:

TCP: Source port = 3464

TCP: Destination port = 443 (Https)

TCP: Sequence number = 105608315

TCP: Next expected Seq number= 105608414

TCP: Acknowledgment number = 1374357434

TCP: Data offset = 20 bytes

TCP: Flags = 18

TCP: ..0. .... = (No urgent pointer)

TCP: ...1 .... = Acknowledgment

TCP: .... 1... = Push

TCP: .... .0.. = (No reset)

TCP: .... ..0. = (No SYN)

TCP: .... ...0 = (No FIN)

TCP: Window = 9520 --------------- > this line is of your interest


TCP: Checksum = E691 (correct)

TCP: No TCP options

TCP: [99 Bytes of data]

TCP:


ADDR HEX ASCII


0000: 00 00 0c 07 ac 01 00 80 c7 22 9d 27 08 00 45 00 | ......"'..E.

0010: 00 8b f8 8c 40 00 80 06 53 c8 a1 2c af 91 d0 b8 | .@..S,

0020: 8c a1 0d 88 01 bb 06 4b 74 7b 51 eb 07 ba 50 18 | ...Kt{Q.P.

0030: 25 30 e6 91 00 00 80 61 01 03 01 00 48 00 00 00 | %0..a....H...

0040: 10 8f 80 01 80 00 03 80 00 01 81 00 01 81 00 03 | ..........

0050: 82 00 01 00 00 04 00 00 05 00 00 0a 83 00 04 84 | .............

0060: 80 40 01 00 80 07 00 c0 03 00 80 00 00 09 06 00 | @...........

0070: 40 00 00 64 00 00 62 00 00 03 00 00 06 83 00 04 | @..d.



Hope this will bring some useful information to you regarding your case.


Still if you want to discuss any thing in this regard kindly revert back me.

I will be very happy if I can be part of any further assistance.

Please do not hesitate to revert back any time.



Till then ,


Kind Regards,

[email protected]


sachinga.hcl Tue, 07/29/2008 - 22:37
User Badges:
  • Silver, 250 points or more

Hi Manjit,


By default, the CSS sends a client-side or server-side TCP window size of 12,288 bytes. You can increase the window size for your specific environment to improve performance. To increase the window size, use the following command:


backend-server server-num tcp virtual|server window bytes


The bytes variable is the window size in bytes. Enter a number from 12288 to 40960. The default value is 12288.


For example, to change the size of the client-side window to 40960 bytes, enter:


(config-ssl-proxy-list[ssl_list1])# backend-server 20 tcp virtual

window 40960

To change the size of the server-side window to 40960 bytes, enter:


(config-ssl-proxy-list[ssl_list1])# backend-server 20 tcp server

window 40960

To reset the default value of 12288 bytes for client-side windows, enter:


(config-ssl-proxy-list[ssl_list1])# no backend-server 20 tcp virtual

window

To reset the default valueof 12288 bytes for server-side windows, enter:


(config-ssl-proxy-list[ssl_list1])# no backend-server 20 tcp server

window



If you experience unacceptable latency in your network due to congestion, you can increase the buffer size that the CSS buffers for a given TCP connection before shutting down the TCP window to 0. Use the backend-server number tcp buffer-share command to set the TCP buffering from the client or server on a given connection. The syntax for this command is:


backend-server number tcp buffer-share rx number1|tx number2


To set the amount of data in bytes that a given connection can buffer from the client traffic, use the rx number1 keyword and variable. By default, the buffer size is 32768. The buffer size can range from 16400 to 262144. For example, to set the value to 65536, enter:


(config-ssl-proxy-list[ssl_list1])# backend-server 1 tcp buffer-share

rx 65536

To reset the buffer size to the default of 32768, enter:


(config-ssl-proxy-list[ssl_list1])# no backend-server 1 tcp

buffer-share rx

To set the amount of data in bytes that a given connection can buffer from the server to the client, use the tx number2 keyword and variable. By default, the buffer size is 65536. The buffer size can range from 16400 to 262144. For example, to set the value to 131072, enter:


(config-ssl-proxy-list[ssl_list1])# backend-server 1 tcp buffer-share

tx 131072

To reset the buffer size to the default of 65536, enter:


(config-ssl-proxy-list[ssl_list1])# no backend-server 1 tcp

buffer-share tx




Kind Regards,


[email protected]

mduhra Thu, 07/31/2008 - 08:49
User Badges:

Hi Sachinga,


The 'window' option is not supported by my CSS. I'm running sg0810106 (08.10.1.06) code.


CSS11501(config-ssl-proxy-list[SSL1])# backend-server 1 tcp server ?

ack-delay Specify the server-side SSL TCP delayed ack timeout

(milliseconds)

inactivity-timeout Specify the server-side SSL TCP inactivity timeout

(seconds)

nagle Specify the server-side SSL TCP Nagle Algorithm State

retrans Specify the server-side SSL TCP min retransmission timer

(milliseconds)

syn-timeout Specify the server-side SSL TCP syn timeout (seconds)


My buffer-share is set to 65kb for both tx/rx. According to ethereal I still have a 11kb TCP window.


I'm wondering if the only option is to upgrade to 8.20 code, which supports the 'window' command ?


Thank you,

Manjit.

Actions

This Discussion